Skip to content

Public API: the second id, for anyone joining to our OnlyFans ingest

A model's account in the public roster now carries both of its upstream ids instead of one. This is the second release today and it reverses a decision announced in the first.

Public API (for integrations)

Each account in the model roster now carries aruna_of_api_id alongside platform_user_id:

GET /api/public/v1/models/
  accounts[] → { platform, platform_name, handle,
                 platform_user_id, aruna_of_api_id, is_active }

Which one to join on depends on what you hold.

You hold Join on Type
OnlyFans' own records platform_user_id integer — OnlyFans' profile.id
Aruna-OF API records aruna_of_api_id string — a UUID

aruna_of_api_id is the row id the Aruna-OF API — the service that ingests these figures — files the account under. If that is where your records come from, you no longer have to go via OnlyFans' id to reach a row you already have the key for.

It is a string, not a number, unlike platform_user_id beside it. Code that assumes both ids are numeric will break on this one.

It is null for any platform with no ingest, which today is everything except OnlyFans. As with every field here the key is always present, so null never has to be told apart from a field that isn't there.

This reverses what the earlier post today said. That one stated the vendor-side id was "still not published and won't be" — true for an arms-length integrator, wrong for anyone working from Aruna-OF records, which is who actually asked. Worth knowing about the promise we have now made: the id is scoped to that vendor rather than to OnlyFans, so if the ingest ever moves to a different service the field stays, reading null. Treat it as a key into Aruna-OF, not as a fact about the platform.

The reference is in the app, at Profile menu → HRIS API. It is generated from the API itself, so it already shows the new field and its guidance on which id to use. Reading it needs an HRIS account — a partner who holds only a key may not have one.

Guide: The API reference

Technical changes

For developers and whoever deploys. None of this needs a guide.

Data model

  • No change. ModelPlatformAccount.external_id has held this value since the OnlyFans link was built; only its publication is new.

Behaviour

  • PublicModelAccountSerializer gains aruna_of_api_id, a read-only CharField sourced from external_id, nullable and blankable. The public API remains an explicit allow-list of named fields, so nothing else moved.
  • The serializer's module docstring records the reversal and its cost rather than deleting the original reasoning.

Deploy

  • Nothing. No migration, no settings, no env, no workers.
  • No pnpm generate: public paths are excluded from the app schema by PREPROCESSING_HOOKS, so the generated client is untouched and the reference renders the field live from schema.json.

Tests

  • Two tests changed meaning rather than being added, because they pinned the opposite of the new behaviour: test_the_platforms_id_is_published_and_arunas_is_not → test_both_upstream_ids_are_published_under_their_public_names, and test_no_platform_ids_leak → test_the_private_column_names_never_leak, which still pins that external_id, external_user_id, of_api_id, of_user_id and email never appear as keys. The values of both ids are public; those spellings are not.