> ## Documentation Index
> Fetch the complete documentation index at: https://confidence.spotify.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Resolution Reference

> Technical reference for flag resolution and application.

This section provides technical specifications and reference information for flag resolution and application.

<Tip>
  For conceptual explanations of flag resolution and application, see [Resolve a Flag](./concepts#resolve-a-flag) and [Apply a Flag](./concepts#apply-a-flag) in the Flag Concepts page.
</Tip>

## Apply a Flag

### Timestamps

Each apply requires two timestamps using the client's local clock:

* `appliedTime`: When the flag value was actually used in the application
* `sentTime`: When the client reports the apply to Confidence

These two timestamps allow accurate tracking without requiring synchronized clocks. The difference helps account for:

* Network latency
* Batching delays
* Offline operation

### Batch Requests

It's recommended to batch apply operations:

* Reduces network overhead
* Saves battery life on mobile devices
* More efficient for the service

Wait for opportune moments (like when doing other network requests) to report applies.

### Mobile and Offline Scenarios

For mobile apps and offline scenarios:

1. Queue applies locally while offline
2. Send all queued applies when network is available
3. Piggyback applies on other API calls
4. Preserve the original `appliedTime` even if sent later

### Handle Errors

Apply operations should be fire-and-forget:

* Log errors for debugging but don't block application flow
* Don't retry immediately to avoid overwhelming the service
* Consider queuing for later retry
* Applying is not critical to UX—the flag has already been resolved

### Monitoring

Track apply metrics to ensure data quality:

* **Apply rate**: How often flags are being applied
* **Apply delay**: Time between `appliedTime` and `sentTime`
* **Apply failures**: How many applies are failing
* **Missing applies**: Flags that were resolved but never applied

### Best Practices

* Apply only when the flag value is actually used
* Batch applies together when possible
* Use accurate timestamps (set `appliedTime` when flag is actually used)
* Handle failures gracefully without breaking application flow
* Queue applies when offline and send when connected
* Monitor apply rates to ensure experiment data is complete