ProxiedMail

Disposable / forwarding email aliases with ProxiedMail — API docs: https://docs.proxiedmail.com/docs/intro, OpenAPI spec: https://proxiedmail.com/api/v1/api-docs.yaml

The API is JSON:API-style REST under https://proxiedmail.com, every path prefixed /api/v1, authenticated with a Token request header carrying the account's static API token.

• Actions: Create Proxy Address, List Proxy Addresses, Update Proxy Address, List Received Emails, Get Received Email.
• Triggers: New Email Received (webhook).

Connection: sign in at proxiedmail.com, open the Settings page (proxiedmail.com/en/settings) and copy the API page token. TaskMagic sends it as Token: <token> on every call — not as Authorization: Bearer. The token is static and does not expire.

Notes

• The webhook trigger carries an account credential, and this piece strips it. ProxiedMail's documented callback body includes a user object holding id, username and token — a full Bearer JWT for the whole account. Delivered as-is, every trigger fire would write that credential into the flow's step output and run history. The trigger removes the entire user key before returning anything, and the raw body is never logged. If you need account details in a flow, fetch them explicitly rather than reading them off the trigger.
• The "webhook" is a field, not a subscription. There is no POST /webhooks resource. A callback is the callback_url attribute on a proxy binding, so New Email Received PATCHes the selected address's callback_url to the TaskMagic webhook URL on enable and clears it back to "" on disable — but only if the field still points at that flow, so disabling one trigger cannot blank a callback something else has since taken over. Consequences: only one consumer can own a given proxy address at a time (the last trigger enabled wins), setting Callback URL by hand in Create/Update Proxy Address on a watched address will stop the trigger receiving anything, and testing the trigger borrows the same field — testing a flow that is already published takes the published copy offline until it is republished.
• real_addresses is serialised three different ways. The same field is an array of strings on POST /proxy-bindings (["[email protected]"]), a map of address → boolean on PATCH /proxy-bindings/{id} ({"[email protected]": true}), and a map of address → status object in every GET response ({"[email protected]": {"is_enabled": …, "is_verified": …}}). The docs put it as "Quite the same as POST request with only one difference in real_addresses." All three conversions live in common.ts; nothing else in the piece touches the raw shape. Anything that re-sends the field reads the binding back first and carries each address's is_enabled across, because the PATCH body is a full representation — re-sending the addresses as a bare list of true would switch forwarding back on for every destination the user had disabled, and sending only the addresses named on a step would drop the rest.
• No Delete Proxy Address action. ProxiedMail publishes no DELETE endpoint for proxy bindings — not in the docs navigation, not in the OpenAPI spec. The closest available operation is disabling a destination address, which Update Proxy Address exposes as Destination Addresses To Disable. Delete the address in the ProxiedMail web UI if you need it gone.
• Non-browsable addresses are invisible to the read actions. is_browsable defaults to Yes here for that reason: with it off, ProxiedMail will forward mail but List Received Emails and Get Received Email cannot see any of it. The docs' own cURL sample passes the string "true"; the field is a boolean, and this piece sends a real boolean.
• List Received Emails returns the last 55 messages, full stop. No pagination, no date filter, no query parameters at all. A busy address silently drops older messages off the end, so treat the list as a recent-activity view rather than an archive.
• No polling trigger, on purpose. GET /received-emails-links/{proxyBindingId} could be polled and deduped on data[].id, but ProxiedMail meters a monthly quota — 2,000 API requests and webhook deliveries per month on the free plan, 10,000 on Plus. A one-minute poll is roughly 43,200 calls a month: it would exhaust a free account's entire allowance in about 33 hours and a Plus account's in under a week, before the flow does any real work. Combined with the 55-message cap, polling would also miss messages on a busy address between runs. The webhook trigger costs one delivery per email instead, so it is the only trigger shipped here. Please do not add a polling variant without redoing this arithmetic.
• Error responses leak server internals. ProxiedMail returns {"data":{"type":"errors","attributes":{"message":…,"exception":…,"file":…,"line":…}}}, where exception, file and line are Laravel class names and absolute server paths. Only message is surfaced to the user; the rest is discarded. The OpenAPI spec types data as an array of these objects while the prose docs show a bare object, so both shapes are parsed.
• No documented HTTP rate limit. No 429 body shape and no Retry-After header appear anywhere in the docs or the spec — the real constraint is the monthly plan quota above. A 429 is still handled, and says so.
• Only the static API token is supported. ProxiedMail also issues a Bearer JWT from POST /api/v1/auth using an email and password, but that token expires and cannot be refreshed — recovering needs a full re-login, which would break every flow using the connection without warning. The email/password login flow is deliberately not implemented.
• No custom API call action. A passthrough would hand this connection's API token to any URL a flow supplies, and every documented endpoint is covered by the actions above.