Sandbox is open
Eight modules for the Nigerian workforce: who a person is, what they can do, on what terms they work, what they are owed, and proof that every part of it happened. Callable infrastructure, not an application with an API bolted on.
No sales call. An account, a key, and a working request in about a minute.
$ curl -X POST https://sandbox.droomwork.io/v1/registrations \
-H 'Content-Type: application/json' \
-d '{"organisation_name":"Acme Ltd",
"email":"dev@acme.example",
"password":"correct-horse-battery"}'
{ "object": "registration",
"sandbox": true,
"api_key": { "key": "dw_test_..." } }
$ curl https://sandbox.droomwork.io/v1/payroll/runs \
-H 'Droomwork-Api-Key: dw_test_...'
{ "object": "list", "data": [], "has_more": false }
The people who reach for these APIs have one of six problems. Most of them have two.
Verify a worker once, engage them on paper that holds, and pay them on Friday without three systems disagreeing about who they are.
Allocate work by location, prove it happened with geofence and passcode evidence, and settle the same day it is proved.
Gross to net for Nigeria with versioned rule packs, every payslip line carrying the formula that produced it, and returns that reconcile to the kobo.
Add payroll, remittance and payouts to a product that already owns the employee record, without becoming a payments company.
Classification decided with its rationale, instruments built from an approved clause library, and the exposure of a misclassification remediated rather than quietly corrected.
One identity for a person across every system that touches them, so a leaver stops being paid everywhere at once.
Hire covers who somebody is and on what terms they work. Pay covers what they are owed and getting it to them. Take one, or take the set.
Identity, one real person, not several accounts.
Is this one person, and are they who they say?
Capability, what a person can actually do.
Can they do the work, and who says so?
Legal standing of the working relationship.
On what terms are they engaged?
Sourcing, broadcast and screened leads.
Where does the next hire come from?
Allocation and proof of service.
Who did the work, and can we prove it?
Gross to net payroll calculation.
What are they owed, to the kobo?
Statutory remittance and proof of it.
Has the state been paid, and where is the receipt?
Getting money into accounts on payday.
Did the money arrive?
Every operation has two samples. They send the same request and get the same answer; the difference is who writes the boilerplate.
An address, a bearer token, a JSON body, and an Idempotency-Key on every write.
For when you want to own every byte, your language isn't one we ship a library for, you're
calling one or two operations, or you already have an HTTP layer of your own.
The same calls in your language's own shapes: typed requests and responses, the address and the token set once, the idempotency key made for you. For when you're integrating a whole module and want a wrong field caught before the API sees it.
The parts nobody wants to build twice, decided once and enforced by the build rather than by a convention.
Every documented endpoint answers with a realistic body, and a record you create is the record you get back. Nothing you do in it is real, and every response says so.
An amount is an integer count of kobo with its currency. No decimal touches the money path anywhere, and a check in CI keeps it that way.
A retry after a timeout cannot do the work twice. The key is claimed before the work runs, so two requests racing take their turn rather than both going through.
Every refusal is a problem document with a code that is stable forever. Branch on the code, never on the message.
Sequence numbers per stream, a published retry schedule, a test trigger, and replay for anything you missed.
The organisation comes from your credential and from nothing you send. Row level isolation in the database, proved by a suite that runs on every change.
Generated from the same documents this reference renders, and compiled on every change, so a sample that does not build never reaches you.
Create a sandbox account and one is issued immediately. It is shown once, carries every sandbox scope, and you can make more or revoke any of them from your dashboard.
No, and it never becomes real by accident. Every response carries sandbox: true and livemode: false. No money moves and no filing is made.
No. Each is bought and integrated separately. They compose when you have more than one, and a module that needs a fact another one owns tells you so rather than guessing.
JavaScript, Python, PHP, Java, C# and Go, generated from the same documents this reference renders, plus cURL for everything. Every one of them is compiled on every change.
The paths do not change. What sits behind them does. An integration built against the sandbox keeps working when the engine replaces the mock.
As a whole number of the currency minor unit plus the currency code. For naira that is kobo, so 1234567 is twelve thousand three hundred and forty five naira and sixty seven kobo.
Create a sandbox account and start calling. Prefer to look first? The reference shows every endpoint, its parameters, an example request and response, and the errors it can return.