Mechanism to identify channel connection/ Return URL

[BjoernRave]

Currently when I use the api to connect a channel i get redirected back to a postiz page, telling me the channel was added. Would it be possible to supply a return_url when doing the connect channel call, so that after the channel connection was successful it redirects back to postiz, also becuase of the return_url needing to be static so it can be provided in the authorized urls of the provider, but then postz would redirect back to my application, ideally with some id of the just connected connection inside so i can store that in my db

[BjoernRave]

---

name: public oauth return_url
overview: Add support for a caller-provided return URL in the public channel OAuth flow, then redirect back to that URL with the canonical Postiz integration ID after successful channel connection.
todos:

• id: add-return-url-query
  content: Extend public social auth URL endpoint to accept/validate return_url and store it in Redis keyed by OAuth state
  status: pending
• id: wire-id-into-redirect
  content: Update frontend OAuth continuation redirect logic to append id (Postiz integration ID) when returnURL is present, including two-step completion
  status: pending
• id: verify-public-oauth-flow
  content: Verify end-to-end public OAuth flow for direct and two-step providers with return_url, ensuring redirected URL includes canonical channel ID
  status: pending
  isProject: false

---

Add Public OAuth return_url Redirect

Goal

Enable GET /public/v1/social/:integration to accept return_url, keep provider callbacks static to Postiz, and after successful channel connection redirect to the caller app with the Postiz channel ID (integration.id) so it can be used for future API calls (posting, channel metadata, etc.).

Implementation

• Update the public OAuth start endpoint in apps/backend/src/public-api/routes/v1/public.integrations.controller.ts:
  • Accept optional query return_url on getIntegrationUrl.
  • Add basic URL-format validation only (per your preference) and reject malformed values with 400.
  • Persist valid value in Redis as redirect:${state} with the same TTL as other state keys.
• Reuse existing callback/connect behavior in apps/backend/src/api/routes/no.auth.integrations.controller.ts:
  • Keep reading redirect:${state} and returning returnURL.
  • Ensure response continues exposing canonical Postiz ID via id (already returned from createUpdate.id).
• Adjust redirect composition in apps/frontend/src/components/launches/continue.integration.tsx:
  • When returnURL exists, redirect to caller URL with merged query params that include the existing success params plus id=<integration.id>.
  • Preserve current fallback behavior for logged-in and non-logged-in flows when returnURL is absent.
  • Ensure two-step providers also pass the same id in final redirect after page/account selection.

API/Behavior Contract

• Public OAuth start call:
  • GET /public/v1/social/:integration?return_url=https://app.example.com/postiz/callback
• On successful connect (and optional second step), Postiz redirects to:
  • https://app.example.com/postiz/callback?...&id=<postiz_integration_id>
• id is the canonical integration identifier accepted by Postiz APIs for channel-scoped operations.

Validation and safety

• Apply only URL-shape validation (new URL(...)-style), no allowlist (as requested).
• Keep provider callback URL unchanged and static (still Postiz frontend URL), so provider authorized redirect requirements stay satisfied.

Verification

• Test one direct provider and one two-step provider via public API flow:
  • OAuth URL generation with return_url.
  • Successful callback -> redirect reaches caller app URL.
  • Redirect includes id and existing status params.
  • Use returned id with public integrations list/details/post endpoints to confirm it is the expected identifier.