A custom API endpoint you’ve built — for your own integration, a mobile app, or another system to talk to your site — failing or erroring out could stem from the endpoint’s own code, authentication, server configuration, or a mismatch with whatever’s calling it, and diagnosing which requires actually tracing a real request through the failure.
Reproduce the exact failing request and capture the full error response
Make the exact same API call that’s failing, capturing the complete error response rather than just noting that it “doesn’t work.” The specific error code and message narrow this down considerably more than a general description of the symptom.
Custom API endpoint errors
A custom API endpoint erroring out, traced to the exact failing request and fixed.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| A custom API endpoint you built is failing or returning errors | This fix covers it |
| The issue is with a third-party API you’re calling, not your own custom endpoint | API rate limit & timeout handling, or the relevant specific third-party integration fix |
| You need a new custom endpoint built from scratch, not an existing one fixed | A different, larger development task — worth describing your requirements directly |
| The endpoint works but is hitting rate limits from too many calls | API rate limit & timeout handling, the more specific version of this concern |
What you are seeing
- The custom endpoint returning an error instead of the expected response
- Some requests succeeding while others fail, suggesting an inconsistent rather than universal problem
- The issue possibly starting after a WordPress core, plugin, or server update
- Authentication failing for requests that previously worked correctly
Common causes
- A bug or logic error in the endpoint’s own code
- Authentication or permission checks failing due to a changed credential or configuration
- A server configuration change (PHP version, security rule) affecting how the endpoint executes
- The calling system sending a request in a format the endpoint no longer correctly handles
- A caching or CDN layer serving a stale, cached response for what’s actually meant to be a dynamic, real-time endpoint
What we do
- Reproduce the failing request and capture the full error response
- Review the endpoint’s code and configuration for the specific cause
- Correct the underlying bug, authentication issue, or configuration mismatch
- Test the corrected endpoint with the exact request that was previously failing
- Verify other, currently working requests to the same endpoint remain unaffected
- Document the fix for future reference
What is included
- The specific cause of the endpoint failure identified and corrected
- A tested, confirmed working endpoint using the exact previously failing request
- Verification other requests to the same endpoint remain unaffected
- The pre-fix backup, kept for 30 days
Not included
- Building a new custom endpoint from scratch, a separate, larger development task
- Fixing issues with a third-party API being called, rather than your own custom endpoint
- Broader rate limit or timeout handling, a separate, related fix if that’s actually the core issue
- Ongoing maintenance as the endpoint’s requirements evolve
Questions about this fix
How do you diagnose a custom endpoint without knowing exactly what it was built to do?
We review the actual code and reproduce the failure directly, which reveals what the endpoint is currently doing and where it breaks — understanding original intent helps, but the code itself and the specific error are the primary diagnostic tools.
Could a WordPress core update really break a custom endpoint?
Yes, particularly if the endpoint relies on specific WordPress functions or behaviour that changed in an update — this is a genuine, ongoing risk with any custom code built against a platform that continues to evolve.
What if the system calling my endpoint is what actually changed, not my endpoint itself?
We'd identify this during diagnosis — if the calling system started sending requests in a different format, the fix might involve updating your endpoint to handle the new format, or coordinating with whoever maintains the calling system.
Will you need access to see who else is calling this endpoint?
Understanding what's calling the endpoint and how helps diagnosis, though we primarily need access to the endpoint's own code and server logs rather than the calling system itself, unless that's also something you control and can share.
Is this something that could happen again in the future?
Yes, since custom code depends on a specific environment and expected inputs staying consistent — a future platform update or a change in what's calling the endpoint could introduce a similar issue again.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.