{"_id":"56cb9a079f4ae20b00644f48","parentDoc":null,"__v":2,"project":"56c35c56c0c4630d004e864c","version":{"_id":"56c35c56c0c4630d004e864f","project":"56c35c56c0c4630d004e864c","__v":8,"createdAt":"2016-02-16T17:28:54.864Z","releaseDate":"2016-02-16T17:28:54.864Z","categories":["56c35c57c0c4630d004e8650","56c7b9e5379b311700ed8fe3","56c7bab4606ee717003c4766","56c7bb3613e5400d001e8cbd","56cf3f5a5267d70b00494c4b","56cf3f866c5d7a13005ee894","56fd3956caad892200847bce","599da256e7742b002588bb02"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"0.5.0","version":"0.5"},"category":{"_id":"56c7bab4606ee717003c4766","project":"56c35c56c0c4630d004e864c","__v":18,"pages":["56c7c193f9aa3b0d00c8458f","56cb80a4c675f50b00a4b826","56cb83859f4ae20b00644f1f","56cb853a245b841300806f82","56cb863c32011d2500681925","56cb88a4245b841300806f8b","56cb9915245b841300806fa7","56cb9a079f4ae20b00644f48","56cb9b5bc675f50b00a4b859","56cba5929f4ae20b00644f5d","56cba5c5d5c6241d00ef5e93","56cbab9c9f4ae20b00644f76","56cbad69c675f50b00a4b881","56cbb060d5c6241d00ef5ebb","56cf3c4d6c5d7a13005ee88c","56cf3d0e287eb20b009f9ec7","56cf3d7c5267d70b00494c42","56cf3ee0287eb20b009f9ecd"],"version":"56c35c56c0c4630d004e864f","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-02-20T01:00:36.607Z","from_sync":false,"order":0,"slug":"buzz-concepts","title":"Buzz Concepts"},"githubsync":"","user":"56c39c05bc41330d009f25d7","updates":["575c37fc28405b0e00c85e5b"],"next":{"pages":[],"description":""},"createdAt":"2016-02-22T23:30:15.146Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"An instance of Buzz supports multiple [Accounts](doc:accounts) with segregated data. However, there are scenarios where multiple instances of Buzz must interact, and the uniqueness of an auto-generated key, such as `account_id`, cannot be assured. To solve this problem, each instance of Buzz includes a \"Buzz Key\", set by the system administrator.\n\nFor most objects in the API, the Buzz Key has no effect. However, for objects that have the potential to be consumed by a shared system, the Buzz Key is used to enforce object uniqueness. For example, in the [Segment](doc:segment) object, there is both a `segment_id` field and a `segment_key` field. The latter is used for targeting segments, sharing segments, and otherwise working with the object. The reason is because segments are often shared between Accounts, and it is possible to imagine a scenario where multiple Buzz instances will need to share segments.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Buzz Key vs account_id\"\n}\n[/block]\nWhen you execute a GET query that includes an `account_id` field, the field will show as a compound key such as `stinger-2` where the Buzz Key is 'stinger' and the numeric `account_id` from the database is 2. Unless you are a [Super User](doc:super-users) (administrator) you can safely ignore the `account_id` field since you cannot POST or PUT objects in other accounts and any GET queries will automatically be restricted to the `account_id` to which you belong.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Conventions\"\n}\n[/block]\nSome considerations about the Buzz Key:\n* Buzz Keys must be unique within the overall Beeswax cloud\n* The value can never be changed once set\n* The value must only use alphanumeric characters\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Usage\"\n}\n[/block]\nWhere Buzz Key is used:\n* The Buzz MySQL database name is in the format `<buzz_key>_<db_name>`\n* The Buzz user cookie is named `<buzz_key>_<cookie_name>`\n* Any GET request that include `account_id` in the response will be formatted as `<buzz_key>-<account_id>`\n* Segments are uniquely identified by the `segment_key` field, which is formatted as `<buzz_key>/<segment_id>`\n* Creative Assets are uploaded to a directory with the path `/<buzz_key>/<account_id>/<advertiser_id>`\n* Segment Uploads are uploaded to a directory with the path `/<buzz_key>/<account_id>`","excerpt":"","slug":"buzz-key","type":"basic","title":"Buzz Key"}
An instance of Buzz supports multiple [Accounts](doc:accounts) with segregated data. However, there are scenarios where multiple instances of Buzz must interact, and the uniqueness of an auto-generated key, such as `account_id`, cannot be assured. To solve this problem, each instance of Buzz includes a "Buzz Key", set by the system administrator. For most objects in the API, the Buzz Key has no effect. However, for objects that have the potential to be consumed by a shared system, the Buzz Key is used to enforce object uniqueness. For example, in the [Segment](doc:segment) object, there is both a `segment_id` field and a `segment_key` field. The latter is used for targeting segments, sharing segments, and otherwise working with the object. The reason is because segments are often shared between Accounts, and it is possible to imagine a scenario where multiple Buzz instances will need to share segments. [block:api-header] { "type": "basic", "title": "Buzz Key vs account_id" } [/block] When you execute a GET query that includes an `account_id` field, the field will show as a compound key such as `stinger-2` where the Buzz Key is 'stinger' and the numeric `account_id` from the database is 2. Unless you are a [Super User](doc:super-users) (administrator) you can safely ignore the `account_id` field since you cannot POST or PUT objects in other accounts and any GET queries will automatically be restricted to the `account_id` to which you belong. [block:api-header] { "type": "basic", "title": "Conventions" } [/block] Some considerations about the Buzz Key: * Buzz Keys must be unique within the overall Beeswax cloud * The value can never be changed once set * The value must only use alphanumeric characters [block:api-header] { "type": "basic", "title": "Usage" } [/block] Where Buzz Key is used: * The Buzz MySQL database name is in the format `<buzz_key>_<db_name>` * The Buzz user cookie is named `<buzz_key>_<cookie_name>` * Any GET request that include `account_id` in the response will be formatted as `<buzz_key>-<account_id>` * Segments are uniquely identified by the `segment_key` field, which is formatted as `<buzz_key>/<segment_id>` * Creative Assets are uploaded to a directory with the path `/<buzz_key>/<account_id>/<advertiser_id>` * Segment Uploads are uploaded to a directory with the path `/<buzz_key>/<account_id>`