> ## Documentation Index
> Fetch the complete documentation index at: https://docs.base44.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Approve scheduled posts
> This API is in beta. Endpoints, fields, and behavior may still change, so avoid depending on it in production.
Approves calendar posts, moving each one from `proposal` to `scheduled`.
Approving doesn't publish anything and doesn't reserve anything. It marks which posts you want sent, and [Start scheduling posts](/api-reference/start-scheduling-posts) is what hands them to the publisher.
Approval is a selection, so one unusable id never discards the rest. The request succeeds with a 200 even when no id could be approved, and the response reports each one: `approved` for the posts that are now `scheduled`, `not_found` for ids that name no live post of this app, and `rejected` for posts past the point of approval, each with the status that blocked it. Repeated ids are collapsed, and re-approving a post that's already `scheduled` reports it under `approved` without changing anything, so calling twice returns the same body.
Send between 1 and 50 ids.
The social calendar endpoints share two rate limits: 20 requests per minute across creating, editing, deleting and approving posts, and 40 requests per minute across the rest. This endpoint counts against the 20.
This endpoint accepts a personal API key. Workspace API keys are not authorized for it and are rejected with a 403.
## OpenAPI
````yaml /developers/references/app-management/app-management-openapi.json post /api/apps/{app_id}/social-calendar/posts/approve
openapi: 3.1.0
info:
title: Base44 App Management API
version: 1.0.0
servers:
- url: https://app.base44.com
security:
- ApiKeyAuth: []
paths:
/api/apps/{app_id}/social-calendar/posts/approve:
post:
summary: Approve scheduled posts
description: >-
This API is in beta. Endpoints, fields, and behavior may still
change, so avoid depending on it in production.
Approves calendar posts, moving each one from `proposal` to `scheduled`.
Approving doesn't publish anything and doesn't reserve anything. It
marks which posts you want sent, and [Start scheduling
posts](/api-reference/start-scheduling-posts) is what hands them to the
publisher.
Approval is a selection, so one unusable id never discards the rest. The
request succeeds with a 200 even when no id could be approved, and the
response reports each one: `approved` for the posts that are now
`scheduled`, `not_found` for ids that name no live post of this app, and
`rejected` for posts past the point of approval, each with the status
that blocked it. Repeated ids are collapsed, and re-approving a post
that's already `scheduled` reports it under `approved` without changing
anything, so calling twice returns the same body.
Send between 1 and 50 ids.
The social calendar endpoints share two rate limits: 20 requests per
minute across creating, editing, deleting and approving posts, and 40
requests per minute across the rest. This endpoint counts against the
20.
This endpoint accepts a personal API key. Workspace API keys are
not authorized for it and are rejected with a 403.
operationId: approve_posts_api_api_apps__app_id__social_calendar_posts_approve_post
parameters:
- name: app_id
in: path
required: true
schema:
type: string
description: ID of the app whose social calendar you want.
title: App Id
description: ID of the app whose social calendar you want.
example: 6820f3a4e7b91d003c45a1f2
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/ApprovePostsPayload'
responses:
'200':
description: The outcome of each id you sent.
content:
application/json:
schema:
$ref: '#/components/schemas/ApprovePostsResult'
'401':
description: Missing or invalid credentials.
'403':
description: >-
You don't have editor access to this app, or you used a workspace
API key.
'404':
description: >-
App not found, or the social calendar is not enabled for your
account.
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
'429':
description: Rate limit exceeded (20 requests per minute).
components:
schemas:
ApprovePostsPayload:
properties:
post_ids:
items:
type: string
pattern: ^[0-9a-fA-F]{24}$
type: array
maxItems: 50
minItems: 1
title: Post Ids
description: >-
IDs of the posts to approve, 1 to 50 of them, as returned by [List
scheduled posts](/api-reference/list-scheduled-posts). Repeated ids
are collapsed.
example:
- 6886b8d390dc7e2f4a2c91b3
- 6886b8d390dc7e2f4a2c91b4
additionalProperties: false
type: object
required:
- post_ids
title: ApprovePostsPayload
ApprovePostsResult:
properties:
approved:
items:
type: string
type: array
title: Approved
description: >-
IDs of the posts that are now `scheduled`, including any that
already were.
example:
- 6886b8d390dc7e2f4a2c91b3
not_found:
items:
type: string
type: array
title: Not Found
description: >-
IDs that name no live post of this app, because the post never
existed or was deleted.
example:
- 6886b8d390dc7e2f4a2c91b9
rejected:
items:
$ref: '#/components/schemas/RejectedPost'
type: array
title: Rejected
description: >-
Posts that are past the point of approval, each with the status that
refused it.
example:
- id: 6886b8d390dc7e2f4a2c91b4
status: posted
type: object
title: ApprovePostsResult
description: >-
Per-id outcome of an approve call.
Approval is a selection, so one unusable id must not discard the rest:
valid
rows transition and the others are reported. Re-approving a row that is
already `scheduled` lands in ``approved`` without a write, which makes a
repeated call return the same body as the first.
HTTPValidationError:
properties:
detail:
items:
$ref: '#/components/schemas/ValidationError'
type: array
title: Detail
type: object
title: HTTPValidationError
RejectedPost:
properties:
id:
type: string
title: Id
description: ID of the post that couldn't be approved.
example: 6886b8d390dc7e2f4a2c91b3
status:
$ref: '#/components/schemas/ScheduledPostStatus'
description: >-
The post's current status, which is why approving it was refused. A
post is only approvable while it's a `proposal`.
example: posted
type: object
required:
- id
- status
title: RejectedPost
ValidationError:
properties:
loc:
items:
anyOf:
- type: string
- type: integer
type: array
title: Location
msg:
type: string
title: Message
type:
type: string
title: Error Type
type: object
required:
- loc
- msg
- type
title: ValidationError
ScheduledPostStatus:
type: string
enum:
- proposal
- scheduled
- publishing
- publish_outcome_unknown
- needs_reconnect
- not_materialized_plan_limit
- paused
- posted
- failed
- deleted
title: ScheduledPostStatus
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: api_key
description: Personal API key.
````