3. Export feeds (you)

  1. Enable "Google Maps Booking API" and "Google Maps Booking API (dev)" for your Cloud project. Go to Developers Console > Enable APIs > Google Maps Booking API > Enable. Then repeat this for the Google Maps Booking API (dev) version. The API marked with (dev) can be used to access the sandbox environment. Learn more about how to enable APIs.

  2. Generate your feeds. You will transmit most of your inventory data to Google via feeds. To do this, create 3 types of feeds:

    1. Merchants feed: descriptions of your merchants
    2. Services feed: description of services your merchants provide
    3. Availability feed: availability slots for services your merchants provide

    You can find examples of all three feeds in Samples section.

    Include metadata in each feed that instructs Google on how to interpret the feed.

    Some fields in these feeds are required and some are optional. Any field marked as optional can be left out of the feed when empty.

    Notes about specific fields:

    • nonce field - make sure that field has a unique value across feed uploads. A good practice is to use a timestamp to guarantee its uniqueness. This value though must be the same across all shards in a feed, it ensures that complete feeds spanning multiple shards are processed together correctly.

    • *_restrict fields - such as service_id_restrict or resources_restrict in availability feed - use them only when you need to narrow down modification scope and to modify existing data rather than provide a complete wipeout. They work essentially as filters to specify a range of data that will be modified. If you use PROCESS_AS_COMPLETE flag and specify restrictions, the data in the selected range will be replaced with the newly provided data.

    • recurrence field - use this field to specify future availability for open slots that have recurring nature instead of providing them explicitly one by one, e.g. a hair dresser that takes appointments every 30 minutes. This field helps not only to reduce the size of your feed, but also to simplify your export process.

    • schedule_exception field is complementary to aforementioned recurrence field and allows to specify breaks or bookings in the regular recurring schedule, e.g. a lunch or coffee break in the daily schedule, or a booking by another customer. An illustration of how to use of both fields together can be found on Special use-cases page - Using recurrence sample.

  3. Export your feeds. The feeds format is described using protocol buffer 3 syntax. You export the feed files in one of two ways:

    • Binary serialization of the protocol buffer data in pb3 format
    • Derived JSON format

    For general information on how to use the protocol buffers to generate a pb3 file, here is an example in Java.

  4. Content Editorial Guidelines. When providing service names and descriptions, make sure to adhere to our Content editorial guidelines.

  5. Upload the feeds to your SFTP Dropbox. Use the Google-provided SFTP sandbox dropbox information from step 2 and the private key you created in step 1A. The Google SFTP server is available at sftp://partnerupload.google.com on port 19321. Please only upload your feeds to the production dropboxes after Google has tested and confirmed your feeds in the sandbox environment.

    Upload your files with unique names (e.g. containing a timestamp). This action helps with troubleshooting and allows querying for feed status.

    Use the following guidelines to determine the size of the feeds and frequency of delivery:

    • Size of feed files and sharding:

      • Keep feed file size below 200MB, and use multiple shards if needed
      • At present we support a maximum of 1000 shards per feed
      • Individual records sent in one shard, doesn't necessarily have to be sent in the same shard in future feeds.
      • For better performance, data should be split fairly among the shards, making all sharded files similar in size.
      • If necessary, use gzip to compress plain text JSON feeds, but do so for each individual feed shards.
    • Frequency of complete updates:

      • Merchants feed: a complete feed once per day
      • Services feed: a complete feed once per day
      • Availability feed:
        • a complete feed once per day
        • the feed should contain no restricts, so all inventory is updated
        • [Fitness and Dining merchants] The complete feed should cover the next 30 days
        • [Beauty merchants] The complete feed should cover the next 90 days
  6. Confirm that your data looks correct in the Partner Portal dashboards. Once you log in to the Partner Portal, toggle to the Sandbox environment, and you will see the following tabs in the Dashboards section:

    • Feeds - This shows the feed summary statistics and points out errors that occurred during feed upload.
    • Booking Server - This shows booking server success and failure rates and latency statistics.
    • Real-Time Updates - This shows API success and failure rates.
    • Live Merchants - This is where you see merchant statistics after you go live. You can ignore this one for the moment.

    In order to confirm that your data looks right after your initial upload to the sandbox environment, check the Feeds tab for any feed errors and then check the Inventory Summary tab for any data issues. Common issues include uploading merchants without any services and services without any availability slots in the future.

    You can also access the Sandbox Frontend which emulates the live UI experience. It shows how the data will look from the user's perspective. To access this, go to the Inventory Details tab, scoll down to the last table called "Enabled Merchants" and click on the Merchant URL for the merchant that you want to see in the sandbox frontend. If there is no data in this table, make sure that your merchants have services and future availability. Also note that this table is only updated every 3 hours, so if you just uploaded the feed, it can take some time for the feed to process and for the data to show up here.

    If you have trouble accessing the sandbox frontend, please confirm that you are logged in with the same account that was whitelisted to access the frontend. Also be sure that this is the only account you are logged into. If you log into a different account and then use the "Switch User" feature to log into the whitelisted Google account, you will still be blocked from accessing the sandbox frontend.

  7. Provide the test merchant_id and confirm feed export to Google. Email your associated Reserve with Google representative with the merchant_id that can be used for testing purposes.

Have questions?

Be sure to check out our FAQs.

Next step

NEXT STEP: Evaluate feeds (Google)