Quora Conversions API destination

[quoraallan0]

Summary

Adds a cloud-mode Actions destination for the Quora Conversions API, so mutual customers can forward Segment conversion events to Quora with configuration only. Opened as a draft to align on the design before implementation.

The full design is in packages/destination-actions/src/destinations/quora-conversions-api/DESIGN.md.

What it does

• Forwards Segment conversion events to Quora's Conversions API (POST https://api.quora.com/ads/v0/conversions), bearer-token auth, batches up to 1,000 events with per-item results.
• Presets map the standard Segment ecommerce events to Quora's conversion types.
• Modeled on reddit-conversions-api (auth, presets, choices), and on the Mixpanel and Amazon destinations for MultiStatusResponse over a 200-with-per-item-results batch response.

Design decisions

• Event field constrained via choices; email mapped and sent plaintext (Quora hashes server-side); performBatch maps per-item results to MultiStatusResponse by returned index; testAuthentication omitted in v1 (Snap-style).

For review

• click_id (qclid) capture: the plan is a browser plugin action that reads qclid from the landing-page URL into the integrations object, with a $.properties.qclid fallback for server-side sources. Is that the pattern you would recommend, or would you rely on the properties and context.page.url path?

API reference: https://www.quora.com/ads/conversion_api_doc

cc @joe-ayoub-segment

[quoraallan0]

A few design questions for review, click_id being the biggest:

1. click_id (qclid) capture: a browser plugin action that reads qclid from the landing-page URL into the integrations object, with a properties fallback for server-side sources, versus relying on properties and context.page.url. Which would you recommend here?
2. Batching vs rate limit: our API caps at 1,000 events/min per account and rejects a whole batch with 429 if it would exceed. Recommended batch size and cadence, and does the framework retry a whole-batch 429?
3. Response handling: the batch endpoint returns HTTP 200 with a per-item results array ({status, index, error_code, error_message}). I plan to map it to MultiStatusResponse the way Mixpanel and Amazon do (mark all success, override errors by the returned index). Right precedent, any gotchas?
4. testAuthentication: we have no lightweight token-check endpoint, so I plan to omit it (Snap-style). Acceptable for GA, or do you expect one?
5. Email: our API expects plaintext email and hashes server-side, unlike other conversions destinations that hash client-side. Any concern with sending plaintext through a cloud-mode destination?

[joe-ayoub-segment]

Hi @quoraallan0 - there's no need to add any more spec to this draft.
I have a pretty good understanding of what needs to be built and will create the destination code in the next day or two. After that we can meet and review together.

Feel free to close this PR as I don't think it's necessary.
Best regards,
Joe