API Integration Troubleshooting: What to Send (and What Not to Send)

Updated 2026-01-21 23:38:38 UTC Created 2026-01-20 22:21:28 UTC

API Integration Troubleshooting: What to Send (and What Not to Send)

STOP: Do not send application logs

Do not export or attach full application logs, log files, or raw debug output when reporting an API integration issue.

Logs often contain sensitive information, multiple unrelated requests, and data we do not need. Sending logs slows down investigation and may expose credentials or personal data.

You must extract only the specific request and response related to the issue and provide that information in a sanitised format, as outlined in this article.

When reporting an API integration issue, it is not enough to say “this issue is happening”. We need the exact request details and the response returned so we can reproduce the problem and identify the cause.

Table of Contents

Overview

To troubleshoot an API integration issue, Easy Employer needs enough detail to reproduce the exact call. The minimum information is the request type, request URL, request headers, request body (if applicable), and the response received.

If this information is not provided, Support cannot reliably confirm what was sent, what the system received, or why the request failed.

Submission template (required)

Copy and paste the template below into your support request and complete each item. Support investigation will not proceed until the required fields are provided.

[ ] Detailed information of the issue:
    - Value:

[ ] Date and time request was made (include timezone):
    - Value:
    
[ ] Request type (GET, POST, PUT, PATCH, DELETE):
    - Value:

[ ] Request URL (complete URL including query parameters):
    - Value:

[ ] Request headers (sanitised, sensitive values redacted):
    - Value:

[ ] Request body (if applicable, sanitised):
    - Value:

[ ] Response received (status code and response body):
    - Status code:
    - Response body:

[ ] Can you reproduce the issue:
    - Yes or No
    - If yes, how often:

[ ] Confirmation:
    - I confirm I have NOT included Authorization tokens, API keys, cookies, passwords, or personal data. details.

What to send (required)

NOTE: Do not send sensitive values such as Authorization headers, API keys, bearer tokens, cookies, passwords, tokens or any personal data. Easy Employer Support will never ask for these. 

Please include the following in your support request.

See section Examples for each required item for what we expect for each item.

Item What we need Example 
Issue description A detailed explanation of the issue, including information of your integration workflows We use the endpoint X to extract employee cost data for payroll processing. This is
Request time Date and time request was made (include timezone) 2026-01-21 at 9:00am AEDT
Request type The HTTP method used GET, POST, PUT, PATCH, DELETE
Request URL (complete URL) The full endpoint you called, including query parameters https://secure.easyemployer.com/org/####/example?param=value
Request headers All headers sent, with sensitive values removed Content-Type: application/json
Request body The payload sent (for POST, PUT, PATCH), with sensitive fields removed {"exampleField":"value"}
Response received Status code and the full response body returned 503 and the returned error payload

What not to send

The following information must not be included in support tickets, screenshots, logs, or attachments.

Sensitive item Common location Required action
Authorization headers (Bearer tokens, API keys) Request headers Replace value with REDACTED
Cookies Request headers Remove or redact
Passwords or secrets Request body or configuration Remove entirely
Personal data Request or response payloads Mask or remove where possible

Do not send full application logs

Do not export or attach full application logs and send them to Easy Employer Support.

Application logs often contain:

  • Multiple unrelated API requests
  • Sensitive authentication information
  • Internal system details that are not required for troubleshooting
  • Data unrelated to the issue being reported
NOTE: If you are using logs to investigate an issue, you must extract only the specific request and response related to the problem and send that information to us. Do not send raw or unfiltered logs. 

The required information must be extracted from your logs and provided in the format outlined in the “What to send” section of this article.

How to capture the request and response

Option A: Postman

  1. Open the request in Postman.
  2. Confirm the correct environment and URL.
  3. Send the request again so the latest response is visible.
  4. Copy and paste:
    • Method and full URL
    • Headers (redact sensitive values)
    • Body (if present)
    • Status code and response body

Option B: Application logs

  1. Locate the log entry for the failing request.
  2. Extract the method, full URL, headers, and body that your integration sent.
  3. Extract the status code and response body that was received.
  4. Redact sensitive values before sending to support.

Option C: Browser developer tools (if the issue is in a browser-based integration)

  1. Open your browser developer tools.
  2. Go to the Network tab.
  3. Reproduce the issue so the failing request appears.
  4. Open the request and capture:
    • Request method and full URL
    • Request headers (redact sensitive values)
    • Request payload (if present)
    • Response status and response body

How to redact safely

Redaction means removing secrets while keeping the structure intact so Support can still troubleshoot.

  • Replace secret values with REDACTED.
  • Do not remove field names or endpoint paths.
  • Do not alter timestamps, status codes, or error messages.

Safe redaction examples:

Authorization: REDACTED
Cookie: REDACTED
x-api-key: REDACTED

Examples for each required item

The examples below show exactly what each required item looks like when provided correctly. All examples are sanitised and safe to share.

Issue description

Good example:

Our integration retrieves approved timesheets from Easy Employer, then our integration pushes them into our payroll system.
The step that retrieves costed timesheets from Easy Employer has started failing. This has not occured before.

The workflow is:
1. Our system calls the Easy Employer cost endpoint to retrieve award interpreted timesheet costs
2. We validate the response and transform the data.
3. We send the transformed data to our payroll system.

The request is now returning a 503 response instead of the expected 200 response.

Incorrect example:

Our integration is now failing and showing 503s.

Request type

The request type is the HTTP method used when calling the API.

Good example:

POST

Other valid examples:

GET
PUT
PATCH
DELETE

Request URL (complete URL)

The request URL must be the full endpoint, including all query parameters.

Good example:

https://secure.easyemployer.com/org/1234/cost?page=1&per_page=100&origin_date_start|gte=1767535200&origin_date_start|lt=1768744740&period=t&user_id=1234

Common incorrect example:

/org/1234/cost
NOTE: Query parameters matter. Missing or incorrect parameters can change results or cause errors. 

Request headers

Provide all request headers that were sent, with sensitive values redacted.

Good example (sanitised):

Accept: application/json
Authorization: REDACTED
User-Agent: PostmanRuntime/7.51.0
Cache-Control: no-cache
Host: secure.easyemployer.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: REDACTED

Incorrect example:

Authorization: Basic TF12enNvaDI3DcpOaTF6SHRpZE12...
NOTE: Never include bearer tokens, tokens API keys, cookies, or secrets. Replace the value with REDACTED. 

Request body

The request body is required for POST, PUT, or PATCH requests.

Good example (sanitised):

{
  "user_id": 1234,
  "date_start": "2026-01-01",
  "date_end": "2026-01-07"
}

When no body is sent:

N/A (GET request)

Response received

Always include both the HTTP status code and the response body.

Good example:

Status code: 503
Response body:
{
  "error": "Service unavailable"
}

Another example:

Status code: 422
Response body:
{
  "error": "Validation failed",
  "field": "date_start"
}

Complete example (all items together)

Request type:
GET

Request URL (complete URL):
https://secure.easyemployer.com/org/1234/cost?page=1&per_page=100&origin_date_start|gte=1767535200&origin_date_start|lt=1768744740&period=t&user_id=1234

Request headers (redacted):
Content-Type: application/json
Authorization: REDACTED

Request body:
N/A

Response received:
Status code: 503
Response body:
{"error":"Service unavailable"}

Date and time request was made (include timezone):
2026-01-21 10:15 Australia/Melbourne

Can you reproduce it:
Yes
TIP: Copying the submission template in this article into your support request will significantly speed up investigation and resolution. 

Common issues that block troubleshooting

  • Sending full application logs instead of extracted request details
  • Missing the full URL (query parameters matter)
  • Providing only a screenshot without request and response details
  • Including secrets or credentials in headers or logs
  • Omitting the response body

Support policy

Easy Employer Support can investigate API integration issues once the minimum required information is provided in a safe and sanitised format.

Support requests that include raw logs or sensitive data will be returned for correction, and investigation will not proceed until the submission template has been completed and sensitive values have been removed.