No API Sandbox? How to Test an Integration Safely
Plan tests with made-up records when a vendor has no separate sandbox. Learn what a mock can prove and what still needs a controlled vendor test.
A sandbox is a separate place to test without changing real business records. If the vendor does not provide one, do not make the live clinic diary your first test bench. Ask about a trial or separate test account. Build the request and failure tests with made-up records first, then agree a small vendor test that cannot contact real patients or take a real slot.
Things to check first
- Ask the vendor what testing it supports. Cliniko's API introduction suggests a free trial for a testing API key. That is a documented option for Cliniko, not proof that every clinic system has a sandbox or that trial behaviour matches every live feature.
- List every action the integration can trigger: booking, email, text, payment, reminder and follow-up. A fake patient name alone does not stop an app from sending a message to a real phone number or blocking a live appointment slot.
- Check that test and live addresses, keys and recipient lists are kept separate. Before allowing writes, verify which account the connection points to. A label saying 'test' is not proof that the destination is isolated.
Postman can simulate API replies from examples. Keep mocks private where needed and use made-up records. Passing these checks does not prove that the real vendor will accept the same request.
Documentation screenshot: Postman. Example screen; yours may look different.What to ask the freelancer to do
- Agree isolated accounts and test cases
- Build or review mock responses
- Run the approved vendor checks
- Report failures, limits and cleanup steps
Questions to ask before hiring
- Which checks use a mock and which use the real vendor?
- How will you block messages and keep real slots free?
- Will I get test steps and a list of what remains untested?
Red flags
- Uses real patient records for convenience
- Treats a mock response as proof the vendor saved a booking
- Runs repeated write or load tests without an agreed account and cleanup plan
Agree what the job includes
- Write a test plan before connecting to the real service. Include a successful booking, invalid data, expired access, a duplicate request, a lost reply, two requests for one slot and a cancellation. Give each case an expected result.
- Use a mock API for repeatable responses such as a rejection, a delay or a temporary error. Postman supports mock servers built from examples. A mock checks how your code reacts to those examples; it cannot prove the real vendor accepts a booking or prevents clashes.
- After local tests, run a vendor-approved test in a separate account where possible. If a limited live test is the only option, get the account owner's agreement on the exact records, time, blocked notifications and cleanup. Do not load-test a live clinic API or copy patient records to create test data.
What to send the freelancer
- Supply the API docs, intended actions and access to an isolated account if available. Use wholly made-up people, contact details and appointment notes.
- Name all connected services that might act on test records. Arrange test inboxes and phone numbers you control, or block those actions entirely.
- Agree who reviews the results, who removes test records and what would stop a test early. Keep a copy of the current integration settings.
How to check the work is done
- The agreed cases have clear results, redacted request examples and a list of any failures. No real patient receives a message or loses an appointment slot.
- The report separates mock-only checks from checks made against the vendor. Untested features and differences between trial and live accounts are stated clearly.
- Test records are removed or marked as agreed, temporary access is revoked and the team receives steps it can repeat after a future change.
What may cost extra
- A mock passing every case is not proof the real vendor integration is ready. Some risks remain until the vendor test is complete.
- Large load tests, a full security audit and repairs found during QA need separate approval and scope. Do not claim legal or clinical compliance from a basic API test.
Sources checked 23 October 2026
Use this guide to agree the work and check the result.
Common questions
Can I test an API with Postman if there is no sandbox?
Yes, Postman can send requests and run mock responses. The destination still matters: sending a write request to a live API can change live records. Start with an isolated account or a mock and agree any vendor test separately.
Can a fake patient name make a live booking test safe?
Not by itself. A test may still reserve time, send reminders or trigger billing. Use an agreed test account and check every connected action, recipient and cleanup step.
Find help on Fiverr
Ready to hand it over? This freelancer offers help with the job covered in this guide. Look at their work and send them your brief to get a quote.
Noman
@mark_grismer · FiverrIndependent API test plan and checks
This listing offers website, app and API testing. Ask for a custom plan covering isolated accounts, mock failures and vendor tests. The basic short functionality check is not the full job described here.
The listing showed 282 reviews when checked. Reviews cover a range of jobs; they do not prove experience with your clinic software.
Before you hire: Agree test accounts, blocked notifications, cleanup and a report separating mock-only checks from real vendor checks. Code repairs are separate.
View service on Fiverr ↗Listing checked 2026-10-23. We have not hired this freelancer or tested their work.
Build my freelancer brief
Answer a few questions to make a clear job description you can send to a freelancer.