Partner Sandbox: Validating a Vendor's Integration Before Production

A step-by-step with the real API calls to give an external partner an isolated environment, with their own token, before granting access to your real API.

The problem with external vendor access

Opening your API to a partner, vendor or external integrator has a recurring dilemma: either they test directly against production (risky), or your team hand-builds a fake environment for every new partner (doesn't scale). httpdrop's Partner Sandbox solves this with an isolated environment per partner — their own token, separate logs, never touching production. See the feature overview if you're not familiar with it yet.

This article is the technical step-by-step — the real API calls, not just the pitch.

Step 1 — enable the sandbox on the endpoint

Sandbox is per-endpoint, and requires the Pro plan or higher (same requirement as the API Portal):

curl -X PATCH https://httpdrop.com/api/endpoints/YOUR_ENDPOINT_ID/sandbox-enabled \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"enabled": true}'

Step 2 — the partner signs up themselves (self-service)

With the sandbox active, the vendor signs up directly — you don't need to manually create a key for each one:

curl -X POST https://httpdrop.com/api/sandbox/YOUR_ENDPOINT_ID/signup \
  -H "Content-Type: application/json" \
  -d '{"name":"Jane Vendor","email":"jane@partner.com","company":"Partner Inc","expiresIn":"30d"}'

{
  "ok": true,
  "token": "sbox_a1b2c3d4...",
  "expiresAt": "2026-09-19T00:00:00.000Z",
  "sandboxUrl": "https://httpdrop.com/sandbox/YOUR_ENDPOINT_ID"
}

🔒

The key only appears once in this response — same as an API token. A 5 signups/hour per-IP rate limit prevents abuse of this public endpoint. Expiration is always required (7, 30 or 90 days) — there's no permanent sandbox key.

Step 3 — the partner uses their token

curl https://httpdrop.com/api/sandbox/YOUR_ENDPOINT_ID/my-requests \
  -H "Authorization: Bearer sbox_a1b2c3d4..."

This route returns only requests made with that specific token — total isolation, one vendor never sees another's traffic.

Managing partners (owner side)

# List all vendors registered in this sandbox
curl https://httpdrop.com/api/sandbox/YOUR_ENDPOINT_ID/partners \
  -H "Authorization: Bearer YOUR_TOKEN"

# Revoke and issue a new key for partner X (the old one stops working immediately)
curl -X POST https://httpdrop.com/api/sandbox/YOUR_ENDPOINT_ID/partners/PARTNER_ID/regenerate \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{"expiresIn":"30d"}'

What the sandbox validates — and what it doesn't

The sandbox proves the vendor knows how to call your API in the right shape — request, headers, call sequence (combine with Response Sequences to simulate flows like login → token → confirmation). It doesn't replace a staging environment with real data and business rules, nor test load or your production backend's behavior — it's the step before those.

🚀

Next step: every partner request counts toward your plan — no separate account per vendor. See the plans to check how many sandboxes/partners each one includes.