Legacy Test Applets Retain Service Key Authentication After IFTTT Connect Migration

Direct Answer

Legacy test applets created before a service migrates to IFTTT Connect will continue to authenticate with the long-lived service key against the legacy Platform endpoint until that endpoint is retired. IFTTT has not published an automatic migration tool that rewrites existing test applets to use the Connect OAuth flow. Each affected test applet must be recreated or reauthorized manually through the Connect authorization flow. CI/CD pipelines that depend on the service key should be updated to perform the full Connect OAuth token exchange (including refresh-token handling) before the legacy Platform sunset.

Confirmed Behavior vs. Likely Explanation

Confirmed from the migration model

• Migration changes the service integration and newly created test resources; it does not rewrite existing applet configuration or stored credentials in place.
• The legacy service-key endpoint remains reachable after migration, so pre-migration test applets continue to function.
• The ifttt test CLI command validates only the legacy service-key path; it does not perform the Connect OAuth handshake.

Likely explanation (not guaranteed by public documentation)

• Legacy test applets are expected to work until the legacy Platform and its service-key endpoint are retired, not until the service's Connect migration date. The late-2025 sunset target is a planning horizon, not a guaranteed availability date.
• Test-mode rate limits and the test_mode: true flag may behave differently between the legacy endpoint and Connect; parity should not be assumed without explicit confirmation or a controlled test.

Steps to Adapt Before Sunset

1. Inventory every test applet and CI job by credential type (service key vs. OAuth tokens), creation date, endpoint called, and whether the test_mode flag is used.
2. Recreate one affected test applet in a non-production service using the Connect authorization flow. Compare trigger execution, scope grants, rate-limit headers/errors, and test_mode behavior against the legacy applet.
3. Update one CI pipeline to perform the complete Connect token exchange: store client ID/secret and a refresh token securely, acquire a short-lived access token at job start, handle expiry/refresh, and send the token with each test request. Verify that authentication failures surface distinctly from applet execution failures.
4. Run a credential-rotation rehearsal only after the inventory is complete: disable the legacy service key temporarily and monitor for both authentication failures and any successful legacy endpoint calls that were missed.
5. Request written confirmation from IFTTT support or the service's migration owner on: the exact legacy test-applet cutoff date, whether any automatic migration will be offered, and the Connect test-mode semantics (rate limits, flag handling, token scope).

One Diagnostic Detail That Changes the Recommendation

If IFTTT publishes a documented, supported migration API or CLI flag that converts existing test applets in place, the manual recreation step can be replaced by that tool. Until such a tool is confirmed, plan for manual recreation.