{ "aid": "gofundme.com:main-2.0.0", "name": "GoFundMe Pro API", "type": "Index", "description": "
Welcome to the GoFundMe Pro API (2.0.0), a powerful toolset that empowers innovative and creative minds to engineer the world for good. This documentation walks through the API’s latest endpoints.
\nGoFundMe Pro APIs are crafted around REST and the REST architectural style to provide developers with a stateless and language-agnostic interface. The GoFundMe Pro API leverages HTTP verbs and response codes, OAuth2 authentication, and resource-oriented URLs.
\nCurrently, the GoFundMe Pro API only supports JSON. All POST/PUT requests required a valid JSON object for the request body.
\nThe GoFundMe Pro API leverages standard HTTP response status codes for it’s error responses. Error codes are:
\n| Error Code | \nMeaning | \n
|---|---|
| 400 | \nBad Request: The request was malformed or provided incorrect/incomplete/conflicting parameters. Check the response for more detailed messaging about why the request was incorrect. Do not repeat request. | \n
| 401 | \nUnauthorized: The API does not recognize the request as authorized. API access token may be missing or invalid. | \n
| 403 | \nForbidden: The API recognizes the authorized API user, but the API user does not have correct permissions to satisfy the request. | \n
| 404 | \nNot Found: The resource requested does not exist or was not found. | \n
| 405 | \nMethod Not Allowed: Some REST endpoints only accept a subset of valid REST HTTP verbs. This error is sent when an unsupported verb is requested. | \n
| 429 | \nToo Many Requests: The rate limit has been exceeded. See the Rate Limiting section for details on rate limits and response headers. | \n
| 500 | \nError: The request was valid, but something failed on the server. Additional messages may be available. | \n
| 503 | \nService Unavailable: The service is temporarily unavailable. | \n
Most API requests will need to be signed with an Access Token.
\nRefer to the Resource Documentation for the specific call you are making to see if an access token is required for your request. See this page for a demonstration of usage through a sample app. \n
We can filter a collection based on a set of input parameters. To do so, we can modify the query string using the parameters listed below.
\n\n| Parameter | \nType | \nDefault | \nDescription | \n
|---|---|---|---|
| with | \nstring | \nN/A | \nThis allows you to include nested related resource. For example, you could request a campaign along with the organization it belongs to and the designation it was allocated to. In this case, with=organization,designation. | \n
| per_page | \ninteger | \n20 | \nSet the total number of resources returned per page (Maximum: 100). | \n
| page | \ninteger | \n1 | \nPage to return. | \n
| sort | \nstring | \nDepends on endpoint | \n\nOrder the resources depending upon their attributes. Examples:\n
| \n
| fields | \nstring | \nDepends on endpoint | \nList of resources attributes separated with comma. Narrow the list of attributes returned for each resource. | \n
| filter | \nstring | \nNULL | \n\nAllow to filter the list of resources returned. Format is: {association}.{attribute1}{operand}{value} where:
| \n
When filtering, the operand should be one of the following:
\n<=, >=, <>, !=, =, <, or >. Operand must be url encoded. (Note: if you are filtering on a boolean value, true can be expressed with true or 1. Additionally, false can be expressed with false or 0).
If filtering on an association, ensure you include the nested resource using the ‘with’ parameter. This allows you to include a nested related resource. For example, you could request a collection of campaigns along with the organization they belong to and the designation they were allocated to. In this case, with=organization,designation.
Refer to the sample documentation for the specific call you are making to see which related resource can be fetched.
\n\nUnless otherwise noted, all Datetime attributes in API responses will be returned in an ISO8601 compliant format:
\n<>YYYY-MM-DDTHH:mm:ss.sssZ (e.g. 2024-10-05T14:48:00.000Z).\nThe GoFundMe Pro API implements rate limiting to ensure fair usage and maintain service quality for all users. Rate limits are applied on a per-application and per-user basis.
\nRate limiting is applied to requests that meet the following conditions:
\nInternal applications are not subject to rate limiting.
\nBy default, the rate limit is:
\nRate limits may be adjusted dynamically via flags for specific applications or users.
\nAll API responses include the following headers to help you track your rate limit status:
\n| Header | \nDescription | \n
|---|---|
X-RateLimit-Limit | \nThe maximum number of requests allowed in the current time window | \n
X-RateLimit-Remaining | \nThe number of requests remaining in the current time window | \n
X-RateLimit-Reset | \nUnix timestamp indicating when the rate limit window resets (only included when limit is exceeded) | \n
Retry-After | \nNumber of seconds to wait before retrying (only included in 429 responses) | \n
When you exceed the rate limit, the API will return a 429 Too Many Requests response with the following structure:
{\n \"message\": \"Too Many Attempts.\",\n \"retry_after\": 42\n}\nThe response will include the Retry-After header indicating how many seconds you should wait before making another request.
X-RateLimit-Remaining header to track your usageRetry-After header value before retryingWelcome to the GoFundMe Pro API (2.0.0), a powerful toolset that empowers innovative and creative minds to engineer the world for good. This documentation walks through the API’s latest endpoints.
\nGoFundMe Pro APIs are crafted around REST and the REST architectural style to provide developers with a stateless and language-agnostic interface. The GoFundMe Pro API leverages HTTP verbs and response codes, OAuth2 authentication, and resource-oriented URLs.
\nCurrently, the GoFundMe Pro API only supports JSON. All POST/PUT requests required a valid JSON object for the request body.
\nThe GoFundMe Pro API leverages standard HTTP response status codes for it’s error responses. Error codes are:
\n| Error Code | \nMeaning | \n
|---|---|
| 400 | \nBad Request: The request was malformed or provided incorrect/incomplete/conflicting parameters. Check the response for more detailed messaging about why the request was incorrect. Do not repeat request. | \n
| 401 | \nUnauthorized: The API does not recognize the request as authorized. API access token may be missing or invalid. | \n
| 403 | \nForbidden: The API recognizes the authorized API user, but the API user does not have correct permissions to satisfy the request. | \n
| 404 | \nNot Found: The resource requested does not exist or was not found. | \n
| 405 | \nMethod Not Allowed: Some REST endpoints only accept a subset of valid REST HTTP verbs. This error is sent when an unsupported verb is requested. | \n
| 429 | \nToo Many Requests: The rate limit has been exceeded. See the Rate Limiting section for details on rate limits and response headers. | \n
| 500 | \nError: The request was valid, but something failed on the server. Additional messages may be available. | \n
| 503 | \nService Unavailable: The service is temporarily unavailable. | \n
Most API requests will need to be signed with an Access Token.
\nRefer to the Resource Documentation for the specific call you are making to see if an access token is required for your request. See this page for a demonstration of usage through a sample app. \n
We can filter a collection based on a set of input parameters. To do so, we can modify the query string using the parameters listed below.
\n\n| Parameter | \nType | \nDefault | \nDescription | \n
|---|---|---|---|
| with | \nstring | \nN/A | \nThis allows you to include nested related resource. For example, you could request a campaign along with the organization it belongs to and the designation it was allocated to. In this case, with=organization,designation. | \n
| per_page | \ninteger | \n20 | \nSet the total number of resources returned per page (Maximum: 100). | \n
| page | \ninteger | \n1 | \nPage to return. | \n
| sort | \nstring | \nDepends on endpoint | \n\nOrder the resources depending upon their attributes. Examples:\n
| \n
| fields | \nstring | \nDepends on endpoint | \nList of resources attributes separated with comma. Narrow the list of attributes returned for each resource. | \n
| filter | \nstring | \nNULL | \n\nAllow to filter the list of resources returned. Format is: {association}.{attribute1}{operand}{value} where:
| \n
When filtering, the operand should be one of the following:
\n<=, >=, <>, !=, =, <, or >. Operand must be url encoded. (Note: if you are filtering on a boolean value, true can be expressed with true or 1. Additionally, false can be expressed with false or 0).
If filtering on an association, ensure you include the nested resource using the ‘with’ parameter. This allows you to include a nested related resource. For example, you could request a collection of campaigns along with the organization they belong to and the designation they were allocated to. In this case, with=organization,designation.
Refer to the sample documentation for the specific call you are making to see which related resource can be fetched.
\n\nUnless otherwise noted, all Datetime attributes in API responses will be returned in an ISO8601 compliant format:
\n<>YYYY-MM-DDTHH:mm:ss.sssZ (e.g. 2024-10-05T14:48:00.000Z).\nThe GoFundMe Pro API implements rate limiting to ensure fair usage and maintain service quality for all users. Rate limits are applied on a per-application and per-user basis.
\nRate limiting is applied to requests that meet the following conditions:
\nInternal applications are not subject to rate limiting.
\nBy default, the rate limit is:
\nRate limits may be adjusted dynamically via flags for specific applications or users.
\nAll API responses include the following headers to help you track your rate limit status:
\n| Header | \nDescription | \n
|---|---|
X-RateLimit-Limit | \nThe maximum number of requests allowed in the current time window | \n
X-RateLimit-Remaining | \nThe number of requests remaining in the current time window | \n
X-RateLimit-Reset | \nUnix timestamp indicating when the rate limit window resets (only included when limit is exceeded) | \n
Retry-After | \nNumber of seconds to wait before retrying (only included in 429 responses) | \n
When you exceed the rate limit, the API will return a 429 Too Many Requests response with the following structure:
{\n \"message\": \"Too Many Attempts.\",\n \"retry_after\": 42\n}\nThe response will include the Retry-After header indicating how many seconds you should wait before making another request.
X-RateLimit-Remaining header to track your usageRetry-After header value before retrying