A failed API request is easier to investigate when its inputs are small and its expected result is clear. This walkthrough uses fictional customer data and a documentation-only example.com address. It does not call a live service or require a real token. Replace the destination only with an endpoint you are authorized to test and follow that API's contract.
Keep the example with its project
Open the relevant DevDesk workspace and use Saved API testing for the request. Record the method, endpoint, required headers and expected response in a note next to the project. Distinguish an expectation taken from the API documentation from a result you actually observed.
Start with the smallest body that reproduces the problem. The fictional customer fixture contains an identifier, a display name and a timestamp. It is a JSON body, not an automatically executable request or a DevDesk workspace export:
{
"id": "8b7b50db-2a87-4fd7-a20f-1b7ff6cbd56c",
"displayName": "Example Customer",
"createdAtSeconds": 1704067200
}
Check the body before the network
Use JSON Tools to validate and format the sample. A trailing comma or an unquoted property name is a syntax issue; a valid JSON number in a field that requires a string is a contract issue. Formatting helps reveal structure but cannot decide whether the receiving API accepts the field names and values.
The UUID guide explains how to generate a distinct fictional identifier. Keep the same identifier when testing an update to one record. A newly generated value can accidentally turn an update investigation into a new-record test. Do not reuse the example ID as a real credential.
Check URL values separately
If a search value contains site report & photos, its component-encoded representation is site%20report%20%26%20photos. Preserve the URL structure around it. Encoding an entire already-built URL can change separators; encoding a value twice can introduce %25 sequences. See URL Encoder and Decoder for the round trip.
Also compare development and production hosts, API versions and path parameters. A correctly encoded value sent to the wrong environment is still the wrong request. Use a supported protected variable for credentials, and review the final resolved request before sending it.
Make time and authentication checks explicit
The sample's 1704067200 represents 1 January 2024 at 00:00 UTC when interpreted as Unix seconds. The millisecond representation is 1704067200000. Use the Timestamp Converter to compare the required unit and display zone. Changing the display zone should not change the instant stored by the API.
If authentication fails, inspect only a synthetic or authorized development token locally. The JWT Decoder makes claims readable; signature validation, accepted issuer, audience and expiry checks still belong to the receiving system. Avoid copying a production token into a public bug report.
Record one observed result at a time
When you run an authorized test, record the response status, relevant response fields and the one input you changed. Keep the original failing example and a separate corrected example rather than overwriting the evidence. Compare the output with the documented contract; an HTTP success code alone does not establish that the correct customer record was changed.
Before sharing, remove authorization headers, cookies, private endpoints and personal data. Keep just the fictional body, method, sanitized path, relevant error and expected behavior. Add a short README explaining the setup and repeat the test from that description. This makes the report useful to another developer without handing over the rest of your workspace.