Migration

Migrating from TUNE, Everflow, Trackier, Affise or CAKE

Import your advertisers, partners, offers and approvals, keep old tracking links and postbacks working, and cut over safely with dual postbacks.

Migration is a feature, not a project. The toolkit imports your data from the other platform's API or from CSV, keeps legacy tracking links resolving, translates their macros, and lets you run both platforms side by side until you switch. Everything is under Settings, Migration in the admin portal and /imports/* in the API (permission imports).

What gets imported

Each imported offer brings its children: goals, payout and revenue entries, caps, landing pages, creatives and postback templates; partners bring their users. Adapters respect each platform's rate limits (for example 4 requests per second for TUNE, 30 for Everflow, 5 for Trackier and Affise) and retry rate-limit responses.

The adapters were built from each platform's published API documentation and tested against recorded fixtures (fixtures/imports/<platform>), not against live accounts. Run a dry run first and compare, as the steps below describe.

The workflow

1. Create a source (POST /imports/sources) with the platform, base URL if self-hosted, API key and (for TUNE and CAKE) network id or admin domain. Credentials are sealed at rest and masked afterwards. POST /imports/sources/{id}/test reads one record to prove the connection.
2. Create a job (POST /imports/jobs) for an API source or for CSV files with a mapping. For CSV, GET /imports/canonical-fields lists the vocabulary and required fields per entity, and POST /imports/mappings/preview shows the effective mapping, problems and the first records before you commit.
3. Dry run (POST /imports/jobs/{id}/dry-run). Nothing is written. You get a diff per record: create, update, skip or conflict, with warnings. Review it in the admin portal or via GET /imports/jobs/{id}/items and download problems from GET /imports/jobs/{id}/errors.csv.
4. Run (POST /imports/jobs/{id}/run). The import works in chunks with a checkpoint: a failed or cancelled job resumes where it stopped (POST .../cancel takes effect between chunks), and re-running is idempotent because every record is tied to its legacy id.
5. Id maps. Every legacy id is stored against the new id (GET /imports/id-maps). They drive link translation and later syncs.

Keep old links and postbacks working

Day-one compatibility means partners do not need new links and advertisers do not need new postback URLs.

• Tracking links. Every tracking domain already understands the legacy link styles. Register the old tracking domains as legacy domains (/imports/legacy-domains) with their style, and point DNS at the edge; the old numeric ids resolve through the id map to the new offers and partners.
• Parameters and macros. GET /imports/legacy/tables/{platform} shows the per-platform parameter and macro translation tables, and POST /imports/legacy/translate rewrites a template or query string (for example TUNE's {aff_sub} to {sub1}). Imported destination URLs and postback templates are translated automatically. See the macros reference for the full registry.
• Postbacks into Metrixed. The advertiser's existing postback URL keeps working if it is pointed at the new tracking domain: the same aliases (transaction_id, aff_click_id, _ef_transaction_id, clickid, sale, and so on) are accepted (tracking methods).

Cutover with dual postbacks

During the transition advertisers still call the old platform. Forward rules (/imports/forward-rules) make Metrixed replay each accepted inbound postback to the legacy platform as well, using a URL template in the legacy platform's macros, with retries and a log (GET /imports/forward-log shows the log and 24-hour counters). The reverse direction (sending your new conversions to a legacy system) is the normal outbound postback.

Forwarding covers conversions created after the rule is switched on; it does not back-fill earlier ones.

The cutover checklist (GET /imports/checklist, PUT /imports/checklist/{step}) has nine steps: connect_source, dry_run, import, verify_ids, legacy_domains, dual_postback, parity, dns_cutover and disable_forwarding. The first six are marked from system state where possible (a source exists, a dry run finished, an import completed, a legacy domain is active, a forwarding rule is enabled); the rest, such as comparing both platforms for a full billing cycle and switching DNS, you tick off by hand with a note.

A typical plan:

1. Import in a dry-run tenant and compare counts, offers and payouts against the old platform.
2. Import for real; keep the old platform live.
3. Turn on forwarding, point old tracking domains at Metrixed, and compare a week of clicks and conversions in both reports.
4. Tell partners and advertisers (the Communication hub has audiences and templates for this).
5. Switch the advertisers' postbacks to the new URL; turn forwarding off.
6. Archive the old account.

Scheduled offer import

Some networks run offers from other networks (you are their affiliate). Settings → Migration → Scheduled imports pulls those offers on a schedule: pick an import source (API credentials of the other network, from the Sources tab), the advertiser the offers belong to (usually the other network), a frequency (every hour, every 6 hours, daily or weekly at an hour in UTC) and filters:

• offer status (for example only active offers),
• name contains,
• only these source offer ids,
• currencies,
• at most N offers per run.

Preview matching offers shows the first page the filters keep, straight from the source. Each run is an ordinary import job: offers seen before are matched through the id map (or adopted by name), new ones are created with their goals, payouts, caps, landing pages and creatives, changed ones are updated. A run that is still going when the next one is due is skipped to the following slot. History lists the runs with created, updated and unchanged counts; Run now queues one immediately.

The API is /import-schedules (list, create, get, update, delete), POST /import-schedules/{id}/run, GET /import-schedules/{id}/runs and POST /import-schedules/preview. Restricted account managers cannot use it.

Known gaps

• Click-time legacy parameter translation runs after the offer's rule sets, so a rule that matches on a legacy sub-id name can miss until the rule is rewritten with the canonical name.
• Historical clicks, conversions and payouts are not imported; only configuration is. Keep exports of the old platform's reports for audit.
• CAKE has no API source for tracking domains; use CSV for those.