# Best practices

The following best practices apply to the Actions Center Local Services Ads End-to-End
integration and can be leveraged to avoid usability and performance issues.
Low data quality might lead to inventory takedown.

## Feeds

- If a service doesn't have a set length, set `duration_sec` in the Availability feed to one of the following:
  - The number of seconds it takes to perform the service in a reasonable manner.
  - The average number of seconds required to complete the service.

    > [!NOTE]
    > **Note:** If a length of `0` is submitted in the feed, our system counts that availability slot as invalid and doesn't show it on the Actions Center.

- Make the `Category` field input in the merchant's feed is specific. For example, a restaurant might submit a specific type, such as French or Japanese. For details, see [Place types](https://developers.google.com/maps/documentation/places/web-service/supported_types) for potential category values.
- Set merchant-specific terms of service in the `Terms` field
  of the Merchant feed so that the following note appears below the
  **Book** button:

  <br />

  > By continuing, you agree to <var translate="no">\<merchant\></var>'s Terms of Service.
  In this case, "Terms of Service" is a link that, when clicked, displays the text set in the *terms* text field.

  <br />

- [Compress your feeds using `gzip`](https://developers.google.com/actions-center/verticals/local-services/e2e/reference/tutorials/compression)

## Booking Server

To optimize your integration of the Maps Booking API, do the following:

- Always use UNIX timestamps in UTC format.
- Generate a unique booking ID when a new booking in the [`CreateBooking`](https://developers.google.com/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-methods/createbooking-method) API is called.

## Real-time updates

To ensure the best user experience during the booking process, do the
following:

- For a standard implementation, use the BookingNotifications API to change the start time, duration, and booking state, such as cancellation or no-show, of an appointment.
- Upon any change on the Actions Center booking from your side, always send real-time booking updates from the system with the BookingNotification API in real-time so that the data doesn't become stale on the Actions Center side. For example, you can cancel, reschedule, or update a booking from your system in the Actions Center.
- For every booking update from `UpdateBookingRequest`, make sure that the `UpdateBookingResponse` value contains the booking ID and that **all** updated fields must reflect the new value.
- If [Inventory RTU](https://developers.google.com/actions-center/verticals/local-services/e2e/integration-steps/real-time-api-updates) are implemented
  - Only update availability in batches of 100-1000 slots per API call.
  - Use `*Restrict` (such as `startTimeRestrict`) fields to narrow the edit target, reduce payload size and avoid re-sending too much unchanged data.
  - If you spin off several threads, implement an [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff) to prevent throttle errors. If you don't implement an exponential backoff correctly, you might get a `RESOURCE_EXHAUSTED` [quota error](https://developers.google.com/actions-center/verticals/local-services/e2e/integration-steps/real-time-api-updates#api-quotas). You can retry the exponential backoff to handle them, but, if you find that your server often reaches quotas when you run `ReplaceServiceAvailability`, configure your server to [batch replace for availability](https://developers.google.com/maps-booking/reference/maps-booking-api/rest/v1alpha/inventory.partners.availability/replace). This solution prevents quota errors because it reduces the number of API calls your serve has to make.
- Set your API call response time limits to less than one second. Ensure that your server can handle five queries per second (QPS) with sub-second latency at least 95% of the time.