Skip to main content
Quick Summary: There is no test mode and no test-key prefix. Develop against the staging server with a key created in a staging tenant, prove the connection with /ping, and hold write scopes back until you need them.

​
One key format, two environments

Every key uses the same sdb_live_ prefix — a key is “test” or “production” only by virtue of which tenant issued it. A key issued in a production tenant performs real operations on real data; nothing about the key stops you. The safe setup is a dedicated staging tenant: ask your SkillsDB contact for one, then create an API key there under Settings → API Credentials exactly as you would in production. The staging server is part of the OpenAPI document:
/ping needs a valid key but no scope — it is the first call to make in any new environment.

​
Habits that pay off

  • Start with read-only scopes. Grant careers:read, people:read and friends while you develop; add :write scopes only when you start writing. :write never implies :read, so nothing is lost by starting narrow.
  • Send Idempotency-Key from day one. Retry behavior is part of your integration, not a production afterthought.
  • Build against the RateLimit-* headers now, while limits are measured but not enforced.
Warning: Staging sends real email. A write that produces notifications — assigning a career, granting a learning — will email the affected people in the staging tenant. Seed staging with addresses you control, not your workforce’s.