> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/developer/rest-api/day-categories.md).
# Day Categories
A day category links a calendar and a schedule. The calendar determines the days of the year that fall into a day category, and the schedule determines what happens at certain times on those days.
The method in this group gives you the day category hrefs you need when creating and modifying schedules. It is a GET: you cannot create or modify day categories using the API.
Day categories are new to the 8.50 API.
### Use case: listing day categories
1. `GET /api`.
2. Follow the link at `features.dayCategories.dayCategories.href`, appending a search term such as `name=substring` or `name="full name"` to filter the selection, and `fields` to tell the server what to return about each day category.
3. Search the results for the day category you are after. With other types of items you would follow the `next` link until there isn't one, but most sites only have a handful of day categories so they will most likely fit on the first page. Especially if you set `top=1000`, which is advised.
### Licensing
Access to day categories requires one of RESTCardholders, RESTStatus, or RESTOverrides.
## Search day categories
> This returns the day categories that match your search criteria.\
> \
> The result will contain no more than 100 or 1000 (depending on your version), or as many as\
> you asked for; you should follow the \`next\` link, if it is present, to\
> collect the next batch. Generally a site does not have too many day categories, so if you\
> set \`top=1000\` you are bound to collect them all.\
> \
> If your result set is empty it means your operator does not have any of the privileges that\
> allow viewing day categories, such as 'View Site', 'Configure Site', or 'Edit Schedules'.\
> Because day categories do not have divisions, having one of those privileges in \_any\_\
> division is enough.\
> \
> When you have seen them all there will be no \`next\` link.\
> \
> This does not take a \`division\` query parameter because day categories are not in divisions.\
> \
> Do not code this URL into your application. Take it from the 'href' field in the\
> \`features.dayCategories.dayCategories\` section of \`/api\`.\
> \
> Added in 8.50.
```json
{"openapi":"3.2.0","info":{"title":"Command Centre REST API","version":"2.0"},"tags":[{"name":"Day Categories","description":"A day category links a calendar and a schedule. The calendar determines the days of the year\nthat fall into a day category, and the schedule determines what happens at certain times on\nthose days.\n\nThe method in this group gives you the day category hrefs you need when creating and modifying\nschedules. It is a GET: you cannot create or modify day categories using the API.\n\nDay categories are new to the 8.50 API.\n\n## Use case: listing day categories\n\n1. `GET /api`.\n\n2. Follow the link at `features.dayCategories.dayCategories.href`, appending a search term such\n as `name=substring` or `name=\"full name\"` to filter the selection, and `fields` to tell the\n server what to return about each day category.\n\n3. Search the results for the day category you are after. With other types of items you would\n follow the `next` link until there isn't one, but most sites only have a handful of day\n categories so they will most likely fit on the first page. Especially if you set `top=1000`,\n which is advised.\n\n## Licensing\n\nAccess to day categories requires one of RESTCardholders, RESTStatus, or RESTOverrides."}],"servers":[{"url":"https://127.0.0.1:8904"}],"security":[{"API_key":[]},{"basic":[]}],"components":{"securitySchemes":{"API_key":{"type":"apiKey","name":"Authorization","in":"header","description":"\nClients authenticate by including a pre-shared API key in the `Authorization` header of each\nrequest after an authorisation method of `GGL-API-KEY`:\n\n`Authorization: GGL-API-KEY C774-B01F-D695-AA4B-215F-A158-AC22-ADEB`\n\nFor a fuller description see [API authentication](api-authentication).\n"},"basic":{"type":"http","scheme":"basic","description":"This is HTTP Basic authentication using a blank username and the API key as the password.\n\nExample: `Authorization: Basic OkM3NzQtQjAxRi1ENjk1LUFBNEItMjE1Ri1BMTU4LUFDMjItQURFQg==`\n\nThat example is equivalent to the example in the description of the api_Key method:\nprepending a colon to the API key beginning with `C774` then encoding it into Base64\nproduces the 56 characters beginning with `OkM3`.\n\nThe colon is a separator between a username, which is blank in our case, and the password,\nwhich is our API key.\n\nFor a fuller description see [API authentication](api-authentication)\n"}},"parameters":{"sort":{"name":"sort","in":"query","schema":{"type":"string","enum":["id","name","-id","-name"]},"required":false,"description":"Changes the sort field between database ID and name.\n\nIf you prefix `id` or `name` with a minus sign (ASCII 45), the sort order is reversed.\n\nThere are two very strong reasons to sort by ID:\n\n1. Sorting by name carries a risk of missing or duplicating objects if your result set spans\n multiple pages and another operator is editing the database while your REST client is\n enumerating them. This is known as \"page drift.\" Sorting by ID does not carry that risk.\n2. Following a `next` link is _dramatically_ quicker when sorting by ID.\n\nWe _strongly_ recommend sorting by ID. In case you were still in doubt, we will do that by\ndefault in a future version of Command Centre.\n\nThe server silently ignores anything except the options listed here.\n"},"top":{"name":"top","in":"query","required":false,"schema":{"type":"integer","minimum":1},"description":"Limits the results to no more than this many items per page.\n\nOlder versions of Command Centre returned 100 items per page in the absence of this parameter. That is acceptable for GUI\napplications that will only display the first page, but for integrations that intend to\nproceed through the entire database it causes a lot of chatter.\n\n8.70 and later versions will default to 1000 items per request. This is about where a graph\nof throughput versus page size begins to level out.\n"},"name":{"name":"name","in":"query","schema":{"type":"string"},"description":"Limits the returned items to those with a name that matches this string. Without surrounding\nquotes or a percent sign or underscore, it is a substring match; surround the parameter with\ndouble quotes `\"...\"` for an exact match. Without quotes, a percent sign `%` will match any\nsubstring and an underscore will match any single character.\n\nThe search is always case-insensitive. Results are undefined if you do a substring search for\nthe empty string (`name=`). You will receive no items if you search for those with no name\n(`name=\"\"`), as all items must have a name.\n\nSearch parameters are ANDed together.\n"},"pos":{"name":"pos","in":"query","required":false,"schema":{"type":"integer"},"description":"Reserved for internal use. You may see it in URLs you receive from the server, but you must never add it yourself."},"skip":{"name":"skip","in":"query","required":false,"schema":{"type":"integer"},"description":"Reserved for internal use. Do not add it to your queries."}}},"paths":{"/api/day_categories":{"get":{"tags":["Day Categories"],"summary":"Search day categories","description":"This returns the day categories that match your search criteria.\n\nThe result will contain no more than 100 or 1000 (depending on your version), or as many as\nyou asked for; you should follow the `next` link, if it is present, to\ncollect the next batch. Generally a site does not have too many day categories, so if you\nset `top=1000` you are bound to collect them all.\n\nIf your result set is empty it means your operator does not have any of the privileges that\nallow viewing day categories, such as 'View Site', 'Configure Site', or 'Edit Schedules'.\nBecause day categories do not have divisions, having one of those privileges in _any_\ndivision is enough.\n\nWhen you have seen them all there will be no `next` link.\n\nThis does not take a `division` query parameter because day categories are not in divisions.\n\nDo not code this URL into your application. Take it from the 'href' field in the\n`features.dayCategories.dayCategories` section of `/api`.\n\nAdded in 8.50.\n","parameters":[{"$ref":"#/components/parameters/sort"},{"$ref":"#/components/parameters/top"},{"$ref":"#/components/parameters/name"},{"name":"fields","in":"query","required":false,"style":"form","explode":false,"description":"This instructs the server to return only these fields in the search results. The values you can list are the field names in the\nschema definitions in this document. Separate values with commas.\n\nUse the special value `defaults` to return the fields you would have received had you not given\nthe parameter at all. Obviously only do that if you have more to add.\n\nTreat the string matches as case-sensitive.\n","schema":{"default":["defaults"],"type":"array","items":{"type":"string","enum":["href","name","description","notes","defaults"]}}},{"$ref":"#/components/parameters/pos"},{"$ref":"#/components/parameters/skip"}],"responses":{"200":{"description":"Success. See the note in the description about privileges if your result set is empty.\n","content":{"application/json":{"schema":{"description":"An array of day categories, and a `next` link for more.","type":"object","properties":{"results":{"type":"array","description":"An array of day categories.","items":{"type":"object","description":"`/api/day_categories` returns an array of these. Each gives you enough\nabout a day category to identify it and use it in a schedule: its href,\nname, and (if you ask for them using the `fields` parameter) notes and\ndescription.\n","properties":{"name":{"type":"string"},"href":{"type":"string","description":"This is the identifier to use when placing this day category on a\nschedule.\n","format":"uri-reference"},"description":{"type":"string","description":"Not in the default field set. If you want it, you need to ask for it\nusing `fields`.\n"},"notes":{"type":"string","description":"Also not in the default field set. If you want it, you need to ask for it.\n"}}}},"next":{"type":"object","properties":{"href":{"type":"string","format":"uri-reference"}},"description":"The link to the next page. Absent if you have retrieved them all."}}}}}},"403":{"description":"The site does not have the RESTCardholders, RESTStatus, or RESTOverrides licence.\n"}}}}}}
```
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://help.security.gallagher.com/knowledge-hub/developer/rest-api/day-categories.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.