@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/claude-code/api-backward-compatibility/SKILL.md

@@ -0,0 +1,170 @@
+# API Backward Compatibility
+
+> BACKWARD COMPATIBILITY IS THE GUARANTEE THAT EXISTING CLIENTS CONTINUE TO WORK WITHOUT MODIFICATION AFTER AN API CHANGE — MASTERING THE ADDITIVE CHANGE RULES, POSTEL'S LAW, AND BREAKING CHANGE TAXONOMY LETS TEAMS EVOLVE APIS RAPIDLY WITHOUT FORCING CONSUMERS INTO LOCKSTEP MIGRATIONS.
+
+## When to Use
+
+- Reviewing a PR that modifies an existing API endpoint to determine whether the change is breaking
+- Designing an API evolution policy for a platform that ships multiple services to external consumers
+- Implementing automated breaking-change detection in a CI pipeline using schema diffing tools
+- Auditing an API whose consumers report unexpected failures after a non-major release
+- Establishing which changes require a new URL version versus which can be deployed to the current version
+- Training a team on the additive-only change model before their first API public launch
+- Choosing between evolving an existing endpoint and introducing a parallel endpoint for a new behavior
+
+## Instructions
+
+### Key Concepts
+
+1. **Additive change rules** — Changes are backward compatible when they only add, never remove or modify existing contracts. Safe additive changes: new optional request fields (with documented defaults), new response fields (existing clients ignore unknown fields), new endpoints, new enum values in responses (clients must handle unknown values), new optional query parameters, and relaxed validation (accepting previously rejected inputs). Each of these leaves existing clients working without modification.
+
+2. **Breaking change taxonomy** — A breaking change is anything that causes an existing valid client to fail or behave differently without a code change. Categories: (a) Removed fields, endpoints, or enum values; (b) Changed field type (string → integer); (c) Changed field semantics (timestamp format, currency unit, pagination behavior); (d) Added required request fields without defaults; (e) Narrowed validation (rejecting previously accepted inputs); (f) Changed HTTP status codes for existing conditions; (g) Changed authentication requirements; (h) Reordered array responses where order was previously stable and clients depended on it.
+
+3. **Postel's Law (Robustness Principle)** — "Be conservative in what you send, be liberal in what you accept." For APIs: accept a wider range of inputs than the minimum required (graceful handling of extra fields, lenient format parsing, ignoring unknown query parameters) and produce tightly specified, minimal outputs. Liberal input acceptance prevents client breakage when clients send slightly different payloads across library versions. Conservative output production prevents clients from depending on undocumented fields that may change.
+
+4. **New enum values are semi-breaking** — Adding a new value to a response enum (`status: "PENDING" | "ACTIVE" | "CLOSED"` → `"PENDING" | "ACTIVE" | "CLOSED" | "SUSPENDED"`) is additive in theory but breaking in practice for clients with exhaustive switch statements that throw on unknown values. Communicate new enum values with advance notice. Recommend in API documentation that clients implement a default case for unknown enum values. Consider using string types with a documented set rather than language-level enums.
+
+5. **Consumer-driven contract testing** — Backward compatibility cannot be verified by inspecting only the provider side. Consumer-driven contract tests (Pact, Spring Cloud Contract) encode each consumer's actual usage as a contract. The provider runs all consumer contracts in CI — if any consumer contract fails against the new provider code, the change is breaking for that consumer. This is the only automated method that catches semantic breaking changes (changed field meaning, changed ordering, changed pagination behavior) that schema diffing misses.
+
+6. **Automated breaking-change detection** — Schema-level breaking changes can be caught with OpenAPI diffing tools (oasdiff, Optic, Speakeasy). These tools compare two API schemas and classify each difference as `non-breaking`, `potentially-breaking`, or `breaking` according to a taxonomy. Integrate in CI: compare the PR's OpenAPI spec against the base branch spec and fail the build on any `breaking` classification. This catches removed fields, type changes, and removed endpoints automatically.
+
+### Worked Example
+
+The Google AIP-180 guidelines define Google's backward compatibility policy for all Google Cloud APIs. Their taxonomy is the most comprehensive publicly available:
+
+**Safe (non-breaking) changes per AIP-180:**
+
+```
+- Adding a new API service
+- Adding a new method to an existing service
+- Adding a new resource field (output only or optional with default)
+- Adding a new enum value (with documented handling of unknown values)
+- Adding a new HTTP binding for an existing RPC
+- Changing a required field to optional (with documented default)
+```
+
+**Breaking changes per AIP-180:**
+
+```
+- Removing or renaming a field, method, enum value, or service
+- Changing the type of a field
+- Adding a required field to a request message
+- Changing an error code for an existing condition
+- Changing the URL path of an existing method
+```
+
+**GitHub API additive evolution — new response field:**
+
+GitHub added the `node_id` field to all resource responses in their REST API as part of their GraphQL migration. This is a textbook additive change: existing clients receive an extra field they ignore, new clients use it for GraphQL interoperability.
+
+```http
+GET /repos/octocat/Hello-World
+Accept: application/vnd.github+json
+```
+
+```http
+HTTP/1.1 200 OK
+
+{
+  "id": 1296269,
+  "node_id": "MDEwOlJlcG9zaXRvcnkxMjk2MjY5",
+  "name": "Hello-World",
+  "full_name": "octocat/Hello-World",
+  ...
+}
+```
+
+Old clients deserializing into a typed model simply ignore `node_id`. Clients that explicitly reject unknown fields (strict mode parsers) would break — GitHub's documentation recommends lenient deserialization for this reason.
+
+**Stripe breaking change taxonomy — a version changelog entry:**
+
+```
+2022-08-01 — Breaking Changes:
+
+REMOVED: PaymentIntent.payment_method_types[] will no longer include "card" by default.
+  Before: { "payment_method_types": ["card"] }
+  After:  { "payment_method_types": [] } — must be set explicitly
+
+CHANGED: Invoice.status_transitions.paid_at changed from Unix timestamp to ISO 8601 string.
+  Before: { "paid_at": 1672531200 }
+  After:  { "paid_at": "2023-01-01T00:00:00Z" }
+
+Migration guide: https://stripe.com/docs/upgrades#2022-08-01
+```
+
+Both are breaking under the taxonomy: the first removes a default value clients depend on; the second changes the type of an existing field.
+
+### Anti-Patterns
+
+1. **Strict unknown field rejection on the server.** Returning `400 Bad Request` when clients send extra fields that the server does not recognize breaks forward compatibility — clients on newer SDK versions that add optional fields will fail against servers on older versions. Fix: apply Postel's Law to input parsing; ignore unknown request fields and log them for observability without rejecting the request.
+
+2. **Trusting schema diffing alone for breaking change detection.** OpenAPI diffing tools catch structural changes (removed fields, type changes) but miss semantic breaking changes: a field whose format changes from `YYYY-MM-DD` to Unix timestamps is structurally identical (both strings or both integers) but semantically breaking. Fix: combine schema diffing with consumer-driven contract tests to catch semantic breakage.
+
+3. **Treating changelog entries as sufficient consumer notification.** Publishing a breaking change in a changelog that consumers must proactively monitor is insufficient for public APIs. Consumers who do not follow changelogs — a majority — will only discover the break in production. Fix: emit `Deprecation` headers on affected responses before the change, and send direct notifications to all consumers with usage of the affected endpoint.
+
+4. **Relaxing then re-tightening validation.** Changing validation from strict to lenient (additive — clients sending previously rejected payloads now succeed) is safe. Reverting that relaxation (re-tightening) is breaking — clients that started sending the previously rejected input in the window between changes will now fail again. Fix: treat validation changes as one-way ratchets; never re-tighten without a version bump.
+
+## Details
+
+### The Field Removal Protocol
+
+Removing a field is one of the most common breaking changes. The safe removal protocol has four stages:
+
+1. **Deprecate in documentation** — Mark the field as deprecated in the OpenAPI spec with a `deprecated: true` annotation and a description pointing to the replacement.
+2. **Emit response with null/empty** — Begin returning `null` or an empty value for the deprecated field while keeping it present in the response shape.
+3. **Remove from documentation** — Stop documenting the field in API reference while still emitting it in responses (allows clients to see it but not depend on new behavior).
+4. **Remove from response** — After the compatibility window expires (and `Sunset` date has passed), stop emitting the field entirely. This is the only stage that is a breaking change under strict definition — stages 1–3 are all compatible.
+
+### Breaking Change Detection in CI with oasdiff
+
+```bash
+# Install oasdiff
+npm install -g @oasdiff/oasdiff
+
+# Compare base branch spec vs PR spec
+oasdiff breaking openapi-base.yaml openapi-pr.yaml
+
+# Exit code 1 on any breaking change — fail CI
+oasdiff breaking openapi-base.yaml openapi-pr.yaml --fail-on-breaking
+```
+
+`oasdiff` classifies each difference and emits structured output listing the breaking classification, the affected path/method, and the change description. Integrate in GitHub Actions:
+
+```yaml
+- name: Check API breaking changes
+  run: oasdiff breaking openapi-main.yaml openapi-pr.yaml --fail-on-breaking
+```
+
+### Real-World Case Study: Stripe Additive Evolution Without Version Bumps
+
+Between 2018 and 2023, Stripe added over 200 new fields to their API responses, introduced 40+ new endpoints, and added 15+ new optional request parameters — all without incrementing the URL version (`/v1/` remains the only version prefix). Each change was classified as additive using their internal breaking-change taxonomy. Their published guidance to SDK authors: "Deserialize response bodies leniently. Unknown fields are features, not errors." Stripe's SDKs implement this by default — the Ruby, Python, and Node SDKs accept unknown response fields and make them accessible as dynamic attributes. This philosophy has enabled 5 years of substantial API evolution with zero forced consumer migrations while maintaining a `/v1/` URL prefix that has been stable since 2011. The lesson: rigorous application of additive-only rules, combined with lenient client deserialization, makes URL version bumps rare rather than routine.
+
+## Source
+
+- [Google AIP-180 — Backwards Compatibility](https://aip.dev/180)
+- [Stripe API Versioning Philosophy](https://stripe.com/blog/api-versioning)
+- [Pact — Consumer-Driven Contract Testing](https://pact.io)
+- [oasdiff — OpenAPI Breaking Change Detection](https://github.com/Tufin/oasdiff)
+- [APIs You Won't Hate — Breaking Changes](https://apisyouwonthate.com/blog/what-is-a-breaking-change)
+
+## Process
+
+1. Publish a breaking-change taxonomy document for the team listing every change category as breaking, non-breaking, or potentially-breaking with examples.
+2. Integrate `oasdiff` or equivalent schema diffing in CI to catch structural breaking changes on every PR against the API spec.
+3. Implement consumer-driven contract tests with Pact for all known consumers, run against every API deployment.
+4. Apply Postel's Law to input parsing: configure request deserialization to ignore unknown fields rather than reject them.
+5. Run `harness validate` to confirm skill files are well-formed and related skills are correctly cross-referenced.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+- **related_skills:** api-deprecation-strategy, api-versioning-url, api-versioning-header, api-contract-testing
+
+## Success Criteria
+
+- A published breaking-change taxonomy document exists and is referenced in the API style guide.
+- Automated schema diffing runs on every PR that touches the API spec and fails the build on breaking changes.
+- All request parsers ignore unknown fields (lenient deserialization) rather than rejecting them.
+- Consumer-driven contract tests exist for all known consumers and run against the provider in CI.
+- New enum values in responses are announced with advance notice and documentation recommends default-case handling for unknown values.

package/dist/agents/skills/claude-code/api-backward-compatibility/skill.yaml

@@ -0,0 +1,39 @@
+name: api-backward-compatibility
+version: '1.0.0'
+description: Additive change rules, Postel's law, breaking change taxonomy, automated breaking-change detection
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - api-deprecation-strategy
+  - api-versioning-url
+  - api-versioning-header
+  - api-contract-testing
+stack_signals:
+  - rest
+  - api
+  - http
+keywords:
+  - backward-compatibility
+  - additive-changes
+  - breaking-changes
+  - Postels-law
+  - robustness-principle
+  - change-detection
+metadata:
+  author: community
+  upstream: aip.dev/180
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/api-bulk-operations/SKILL.md

@@ -0,0 +1,198 @@
+# Bulk Operations
+
+> BULK ENDPOINTS AMORTIZE PER-REQUEST OVERHEAD ACROSS MANY OPERATIONS IN A SINGLE HTTP CALL — BUT THE REAL DESIGN CHALLENGE IS WHAT TO RETURN WHEN SOME OPERATIONS SUCCEED AND OTHERS FAIL: TRANSACTIONAL SEMANTICS ROLL BACK EVERYTHING ON ANY ERROR WHILE BEST-EFFORT SEMANTICS COMMIT SUCCESSES AND REPORT FAILURES INDIVIDUALLY, AND CHOOSING THE WRONG MODEL PRODUCES SILENT DATA CORRUPTION OR WASTED RETRIES.
+
+## When to Use
+
+- Designing an import endpoint that creates or updates hundreds of records from a CSV upload
+- Implementing a bulk delete for a UI that allows multi-select and mass removal
+- Building a notification service that sends messages to thousands of recipients in a single API call
+- Reducing the number of round trips for a client that must create 50 resources sequentially
+- Reviewing a PR that loops over individual create/update/delete endpoints in a batch job
+- Choosing between all-or-nothing transaction semantics and best-effort per-item semantics for a batch endpoint
+- Adding `Idempotency-Key` support to a bulk create endpoint that may be retried on network failure
+- Designing partial failure responses and deciding which HTTP status code to return when some items fail
+
+## Instructions
+
+### Key Concepts
+
+1. **Bulk Create, Update, and Delete** — A bulk endpoint accepts an array of operation items in the request body and executes them as a collection. The three primary patterns are:
+   - **Bulk create:** `POST /resources/bulk` with a body `{"items": [...]}` creates multiple resources in one request.
+   - **Bulk update:** `PATCH /resources/bulk` applies a set of patch operations to multiple existing resources.
+   - **Bulk delete:** `DELETE /resources/bulk` with a body listing resource IDs, or `POST /resources/bulk-delete` for clients that cannot send DELETE bodies.
+
+2. **Transactional vs. Best-Effort Semantics** — This is the most consequential design decision for a bulk endpoint:
+   - **Transactional:** All items are applied in a single database transaction. If any item fails validation or encounters an error, the entire batch is rolled back. The response is either `200 OK` (all succeeded) or `422 Unprocessable Entity` / `400 Bad Request` (none were applied, with per-item errors). Use this when partial application would leave data in an inconsistent state.
+   - **Best-effort:** Each item is applied independently. Successes are committed; failures are reported per-item. The response uses `207 Multi-Status` with a per-item result array. Use this when partial success is acceptable (e.g., sending notifications — some succeed, others fail) and callers can retry only the failed items.
+
+3. **207 Multi-Status Response** — When using best-effort semantics, return `207 Multi-Status` with a body that maps each input item to an individual status code and optional error detail:
+
+   ```json
+   {
+     "results": [
+       { "index": 0, "status": 201, "id": "res_001" },
+       {
+         "index": 1,
+         "status": 422,
+         "error": { "code": "validation_failed", "message": "name is required" }
+       },
+       { "index": 2, "status": 201, "id": "res_003" }
+     ]
+   }
+   ```
+
+   The outer HTTP status is `207` regardless of how many items failed. Never return `200 OK` for a best-effort batch where some items failed — it misleads callers into thinking all items succeeded.
+
+4. **Idempotency-Key on Bulk Endpoints** — A bulk create endpoint that fails mid-way through leaves the caller uncertain about which items were created. Re-submitting the full batch without an idempotency key will duplicate items. Accept an `Idempotency-Key` header on bulk create and bulk update endpoints. Store the key with a short TTL and replay the previous response on a duplicate submission. For best-effort batches, the idempotency key covers the entire batch — if the batch partially succeeded and the client retries with the same key, replay the original (partial success) response rather than re-executing.
+
+5. **Request Size Limits** — Impose an explicit maximum on the number of items per batch and the total request body size in bytes. Document both limits. Common limits: 100–1,000 items per batch, 5–10 MB body size. Requests exceeding these limits should return `413 Content Too Large` (body size) or `400 Bad Request` (item count) with the limits stated in the error body. Do not silently truncate the input.
+
+6. **Ordering and Dependency** — Document whether the items in a bulk request are processed in order and whether later items may depend on earlier ones (e.g., bulk create where item 2 references the ID of item 1). Most bulk endpoints treat items as independent and process them in unspecified order. If ordering matters, process sequentially in input order and stop on first failure (transactional) or continue and report each failure (best-effort).
+
+### Worked Example
+
+Stripe's Bulk operations pattern via the Batch API demonstrates the design of a transactional batch using per-operation result codes:
+
+**Bulk create price and product in a single batch call:**
+
+```http
+POST /v1/batch
+Content-Type: application/json
+Authorization: Bearer sk_example_...
+Idempotency-Key: batch_20240315_import_001
+
+{
+  "requests": [
+    {
+      "method": "POST",
+      "url": "/v1/products",
+      "body": "name=Widget+Pro&description=Our+flagship+product"
+    },
+    {
+      "method": "POST",
+      "url": "/v1/prices",
+      "body": "product=prod_abc&unit_amount=2999&currency=usd"
+    }
+  ]
+}
+```
+
+```http
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+  "results": [
+    {
+      "status": 200,
+      "body": {
+        "id": "prod_abc123",
+        "object": "product",
+        "name": "Widget Pro"
+      }
+    },
+    {
+      "status": 200,
+      "body": {
+        "id": "price_xyz789",
+        "object": "price",
+        "unit_amount": 2999,
+        "currency": "usd",
+        "product": "prod_abc123"
+      }
+    }
+  ]
+}
+```
+
+**Bulk delete with best-effort semantics (207 Multi-Status):**
+
+```http
+POST /api/v1/messages/bulk-delete
+Content-Type: application/json
+Authorization: Bearer token_...
+
+{
+  "ids": ["msg_001", "msg_002", "msg_003"]
+}
+```
+
+```http
+HTTP/1.1 207 Multi-Status
+Content-Type: application/json
+
+{
+  "results": [
+    { "id": "msg_001", "status": 204 },
+    { "id": "msg_002", "status": 404, "error": { "code": "not_found", "message": "Message not found" } },
+    { "id": "msg_003", "status": 204 }
+  ],
+  "summary": { "succeeded": 2, "failed": 1 }
+}
+```
+
+### Anti-Patterns
+
+1. **Returning `200 OK` when some items in a best-effort batch failed.** A `200 OK` response signals complete success to HTTP clients, middleware, and monitoring systems. If item 3 of 10 failed and the response is `200 OK`, automated retry logic and dashboards will not flag the failure. Return `207 Multi-Status` for any best-effort batch response that contains a mixture of success and failure, or `422`/`400` for a transactional batch that failed entirely.
+
+2. **Silently truncating batches that exceed the size limit.** If a client sends 500 items and the server's limit is 100, silently processing only the first 100 and returning success causes the caller to believe all 500 were processed. The remaining 400 items are silently dropped. Always validate the item count before processing and return `400 Bad Request` with the limit in the error body if exceeded.
+
+3. **Applying transactional semantics to operations that cannot be rolled back.** If a bulk endpoint sends emails, charges cards, or triggers external webhooks as each item is processed, these side effects cannot be rolled back when a later item fails. Applying transactional semantics implies rollback is possible. Use best-effort semantics for operations with irreversible external side effects, document the semantics clearly, and design callers to handle partial success.
+
+4. **Omitting per-item indexing in the error response.** A `207` response that lists errors without correlating them to the input items forces callers to guess which items failed. Always include the input index (0-based or 1-based, consistently) or the input item's client-provided ID in every result entry. This allows callers to retry only the failed items without re-submitting the entire batch.
+
+## Details
+
+### Choosing Transactional vs. Best-Effort
+
+| Factor                          | Transactional                         | Best-Effort                         |
+| ------------------------------- | ------------------------------------- | ----------------------------------- |
+| Data consistency requirement    | Strong — all or nothing               | Eventual — partial success OK       |
+| External side effects           | None or fully reversible              | Possible; cannot be rolled back     |
+| Retry behavior                  | Client retries full batch             | Client retries failed items only    |
+| Response status on partial fail | `400`/`422` — nothing applied         | `207` — successes committed         |
+| Database transaction            | Single transaction                    | Per-item transactions               |
+| Use cases                       | Financial ledger, referential imports | Notifications, bulk tag application |
+
+### Idempotency Key Scope for Bulk
+
+When a client retries a bulk request with the same `Idempotency-Key`:
+
+- **Transactional batch that fully succeeded:** Replay the original `200 OK` response. Do not re-execute.
+- **Transactional batch that fully failed:** Re-execute (the original transaction was rolled back; no state change occurred).
+- **Best-effort batch:** Replay the original `207` response. Do not re-execute any item, including failed items. The client should re-submit only the failed items with a new idempotency key.
+
+### Real-World Case Study: Mailchimp Batch API
+
+Mailchimp's `/3.0/batches` endpoint processes bulk subscriber list updates asynchronously. Synchronous per-subscriber API calls for a 10,000-subscriber import produced approximately 35 minutes of sequential HTTP round trips from clients with standard connection limits. After migrating to the batch API, the same 10,000-subscriber import completed in under 90 seconds — a 23x throughput improvement. The batch API uses best-effort semantics and returns an operation ID immediately; clients poll `GET /3.0/batches/{batch_id}` for completion and retrieve a per-item error report from a signed S3 URL included in the completed batch response.
+
+## Source
+
+- [Stripe Batch API](https://stripe.com/docs/api/bulk)
+- [RFC 4918 — HTTP Extensions for WebDAV (207 Multi-Status)](https://www.rfc-editor.org/rfc/rfc4918#section-13)
+- [Mailchimp Batch Operations](https://mailchimp.com/developer/marketing/api/batch-operations/)
+- [Microsoft Graph Batch Requests](https://learn.microsoft.com/en-us/graph/json-batching)
+- [Stripe Idempotency Keys](https://stripe.com/docs/api/idempotent_requests)
+
+## Process
+
+1. Decide on semantics: transactional (all-or-nothing, single DB transaction, return `400`/`422` on any failure) or best-effort (per-item commit, return `207 Multi-Status` with per-item results). Document the choice in the API reference.
+2. Define and enforce request limits: maximum item count, maximum body size in bytes. Return `413 Content Too Large` or `400 Bad Request` with limits in the error body for violations.
+3. Add `Idempotency-Key` header support. Store the key with the full response and TTL. On duplicate submission, replay the stored response without re-executing.
+4. Implement per-item result reporting: every result entry must include the input index or client-provided ID, the HTTP status for that item, and for failures, a machine-readable error code and human-readable message.
+5. For best-effort batches with external side effects (email, webhooks, charges), document that failed items are not retried by the server and callers are responsible for resubmitting failures.
+
+## Harness Integration
+
+- **Type:** knowledge -- this skill is a reference document, not a procedural workflow.
+- **No tools or state** -- consumed as context by other skills and agents.
+- **related_skills:** api-idempotency-keys, api-error-contracts, api-http-methods, api-status-codes
+
+## Success Criteria
+
+- Bulk endpoints with best-effort semantics return `207 Multi-Status`, never `200 OK`, when any item fails.
+- Per-item results in `207` responses include the input index or client-provided ID for every item, success or failure.
+- Request size limits (item count and body bytes) are enforced and documented; violations return `400`/`413` with the limit values in the error body.
+- Bulk create and bulk update endpoints accept and honor `Idempotency-Key` headers; duplicate submissions replay the stored response without re-executing.
+- API documentation explicitly states whether semantics are transactional or best-effort for every bulk endpoint.

package/dist/agents/skills/claude-code/api-bulk-operations/skill.yaml

@@ -0,0 +1,39 @@
+name: api-bulk-operations
+version: '1.0.0'
+description: Batch endpoints including bulk create/update/delete, partial failure semantics, transactional vs best-effort batches, and Idempotency-Key on bulk
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - api-idempotency-keys
+  - api-error-contracts
+  - api-http-methods
+  - api-status-codes
+stack_signals:
+  - rest
+  - api
+  - http
+keywords:
+  - bulk-operations
+  - batch
+  - partial-failure
+  - 207-multi-status
+  - transactional-batch
+  - best-effort-batch
+metadata:
+  author: community
+  upstream: stripe.com/docs/api/bulk
+state:
+  persistent: false
+  files: []
+depends_on: []