Endpoints
Both endpoints require
X-API-Key.
Submit batch body
Each item wraps the full subscriber object (same shape as provider-initiated provisioning) plus aplan_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.