Skip to main content
Cresora Commerce
Getting Started

First API Call

Make a test API call to verify your credentials and environment setup.

Before processing a payment, verify your setup with a simple authenticated request.

Verify authentication

Call GET /partner/me. It returns the partner record bound to your API key, takes no parameters, and needs no merchant and no payment instrument — so it isolates one question, is my credential good?, from everything that could go wrong later.

curl https://api.sandbox.cresoracommerce.ai/api/v1/partner/me \
  -H "Authorization: Bearer csk_ab12cd34_xxxxxxxxxxxxxxxxxxxxxxxx"
ℹNote

Deliberately not a payment. A charge needs a merchant_id and a vaulted card (cvt_…) obtained from a hosted-page save-card flow, so a failed charge has several possible causes and only one of them is your key. Prove the key first.

Expected responses

HTTP statusCodeMeaning
200 OKn/aKey is valid. The body is your partner record, including id, name, contact_email, partner_type, state and rate_limit_tier
401unauthorizedKey is missing, malformed, expired, or rotated; re-copy it from Partner Portal
403unauthorizedKey is valid but does not hold partner:read — or it is an admin-scope key, which this endpoint rejects by design

No Idempotency-Key on this call: it is a read, and the header is required only on writes.

Idempotency, for the writes that follow

Every write request (POST, PUT, PATCH) requires an Idempotency-Key header — in the sandbox exactly as in production. There is no environment that relaxes this: a write without the header is rejected with 400 idempotency_key_required before it reaches any processing. Use a fresh UUID per request:

-H "Idempotency-Key: idem_$(uuidgen)"

Next

Proceed to First payment → to run a complete payment flow with test card data.