See Bulk Provisioning for the full guide.

Endpoints

Both endpoints require X-API-Key.

Submit batch body

Each item wraps the full subscriber object (same shape as provider-initiated provisioning) plus a plan_version_id, a location_hash or location_identifier (at least one; hash preferred), and optionally the same billing block as the single endpoint (owner, stripe_customer_id, billing_day — see provider-initiated provisioning). 1–100 items per batch.

Response — 200 OK (synchronous)

The POST processes every item inline (subscriber + subscription created, SSH job queued) and returns per-item results — not a 202:
status per item is "queued" or "error". Failed items don’t stop the rest of the batch. billing_owner is "kurnl" or "partner" on a queued item and null on a failed one. An item that asked for kurnl billing and failed the billing pre-flight reports the reason in error, prefixed with the code (billing_not_available, stripe_customer_not_found, stripe_customer_has_no_payment_method, stripe_customer_in_use, stripe_unavailable).

Poll response

GET /partner/provisioning/bulk/{batch_id}:
job_status is one of pending, running, completed, failed, error, unknown. There is no batch-level aggregate status — the batch is done when no item is pending or running.

Errors & limits

Batch results are retained for 30 days. Retrying failed items is safe: provisioning is idempotent per item — the same subscriber email + plan version + location returns the existing subscription instead of creating a duplicate.