Understanding Why Fax Headers Use UTC with the send_time Parameter in the Fax.Plus API

When sending a fax via the Fax.Plus API, you may notice that the timestamp printed in the fax header appears in UTC, even when you include a timezone offset (for example, +0900 for JST) in the send_time field.

Understanding the send_time parameter

• The send_time field is optional.
• If omitted, the fax is sent immediately, and the fax header timestamp is generated using UTC, which is the standard timezone used by us.
• If provided, send_time allows you to schedule a fax for a specific date and time, including a timezone offset.
• Supported format: 
  YYYY-MM-DD HH:mm:ss +HHMM
  Example:
  "send_time": "2025-12-19 09:00:05 +0900"

Important behavior to be aware of

If the value of send_time is in the past at the moment the API request is received - even by one second - the system will:

• Ignore the provided send_time
• Send the fax immediately
• Set the fax header timestamp to UTC

This behavior ensures reliable processing of immediate transmissions and prevents failed or delayed jobs due to invalid scheduling times.

Why this can appear inconsistent

You may observe different behavior depending on where your API request originates:

• Local environments may send the request quickly enough that send_time is still in the future.
• Cloud environments may introduce small delays, causing send_time to be interpreted as already elapsed.

In these cases, the fax is processed as an immediate send, and the header timestamp defaults to UTC.

How to ensure your timezone is preserved

To ensure the timezone specified in send_time is respected:

✅ Always schedule the fax slightly in the future
We recommend setting send_time at least 1–2 seconds ahead of the current time.

Example best practice:

Current time: 09:00:00 +0900
send_time:    09:00:02 +0900

This ensures the request is treated as a scheduled fax and the timezone offset is preserved in the fax header.

Key takeaways

• send_time is optional
• Fax headers default to UTC for immediate sends
• If send_time is in the past, it is ignored
• Scheduling even a few seconds ahead prevents UTC fallback

If you have additional questions or need help troubleshooting your API integration, feel free to contact our support team.