Skip to main content
Mobile and offline-first clients should not re-download an entire wardrobe on every launch. The Drssed sync endpoints let you fetch only what has changed since your last successful sync. By passing a timestamp, you get back a compact diff: the items that were added or updated, the IDs of items that were deleted, and a new server timestamp to use next time. This keeps your local store consistent without the overhead of a full fetch.
Both sync endpoints require authentication. Include your Authorization: Bearer {token} header on every request.

​
How the sync model works

Both GET /users/me/clothing/sync and GET /users/me/outfits/sync follow the same pattern:
  • Pass an optional updated_since query parameter in ISO 8601 format (e.g. 2024-01-01T00:00:00Z).
  • If you omit updated_since, the server returns all items from the beginning of time — useful for an initial load.
  • The response always contains three fields:
    • updated — an array of items that were created or modified after updated_since
    • deleted — an array of IDs for items that were soft-deleted after updated_since
    • server_time — the current server time, which you should store and use as updated_since on your next sync
Always use the server_time value from the response as your next updated_since — not the current time on the client device. This avoids bugs caused by timezone differences or clock skew between your client and the server.

​
Sync clothing

Call GET /users/me/clothing/sync to get incremental clothing updates.

​
Sync outfits

Call GET /users/me/outfits/sync to get incremental outfit updates. The response structure is identical to the clothing sync.
Here is the client-side loop you should implement to keep your local store in sync:
1

Store the server_time locally

After every successful sync, persist the server_time value from the response. On a first-ever sync, omit updated_since entirely to fetch all data.
2

Pass stored server_time as updated_since

On subsequent syncs, include the stored server_time as the updated_since query parameter. The server returns only items changed after that point.
3

Apply updated items to your local store

Upsert each item in the updated array. If an item already exists locally, replace it with the new version. If it is new, insert it.
4

Remove deleted items

For each ID in the deleted array, remove the corresponding item from your local store. These items have been soft-deleted on the server.
5

Store the new server_time

Replace your previously stored server_time with the new one from this response. This becomes the updated_since for your next sync.

​
Rate limits

Both sync endpoints are limited to 5 requests per minute. If you exceed this limit the API returns 429 Too Many Requests. On mobile clients, consider triggering a sync on app foreground rather than on a fixed timer to stay within the limit.