Sandbox environment

The sandbox is a standalone mock server — not a mode on the production API. It has no database and no access to real Vine data. Point any SDK's base URL override at it instead of auth-api.vineeid.com / api.vineeid.com and it works with no code changes, since every SDK already supports overriding the base URL.

It accepts any API key. There's nothing real behind it, so there's nothing to protect.

Run it

bash
git clone <this repo> && cd sandbox-server
cargo run
# or:
docker build -t vine-sandbox-server . && docker run -p 8081:8081 vine-sandbox-server

Point your SDK at http://localhost:8081.

UAP (auth) flow

The six methods every SDK documents are implemented with real in-memory state, so you can watch a full approval lifecycle:

bash
curl -X POST localhost:8081/api/flow/init \
  -H "x-api-key: anything" -H "Content-Type: application/json" \
  -d '{"vid":"657787756543","request_type":"login","scope":"[\"profile.read\"]"}'

Poll GET /api/flow/{flow_id}?flow_secret={flow_secret} — the flow reports pending on the first poll and approved from the second poll onward, so you can exercise your app's full pending → approved handling without waiting on a real device.

Vendor API

All documented Vendor API paths are mocked automatically from the same OpenAPI spec that powers the API reference, so the shape of every response matches the real API. The data itself is placeholder — schema-typed defaults, or the spec's own example values where provided — not semantically meaningful records.

Limitations

  • State resets whenever the sandbox restarts.
  • Every flow approves after 2 polls; there's no way to simulate rejection or expiry yet.
  • No rate limiting, no webhooks, no persistence.

These are sandbox conveniences, not bugs — for load testing or webhook integration testing, request real sandbox credentials from support instead.