메인 콘텐츠로 건너뛰기
참고: X API v2에서 게시물 검색과 게시물 집계의 새 버전을 출시했습니다. X API v2의 신규 사항을 검토하시길 권장합니다. 이 엔드포인트는 게시물 편집 메타데이터를 포함하도록 업데이트되었습니다. 자세한 내용은 “게시물 편집” 기본 사항 페이지를 참고하세요. 

​
개요

Enterprise Enterprise API는 관리형 액세스 레벨에서만 사용할 수 있습니다. 이 API를 사용하려면 먼저 엔터프라이즈 영업팀과 계정을 개설해야 합니다. 자세한 내용은 여기를 참조하세요. X API 검색 게시물 제공 항목은 모두 여기에서 확인할 수 있습니다. 엔터프라이즈 검색 API는 두 가지가 있습니다:
  1. 30-Day Search API는 직전 30일의 데이터를 제공합니다.
  2. Full-Archive Search API는 2006년 3월 첫 게시물까지 거슬러 올라가는 X 데이터 전체 코퍼스에 완전하고 즉시 액세스할 수 있도록 제공합니다.
이 RESTful API들은 요청당 최대 2,048자의 단일 쿼리를 지원합니다. 쿼리는 PowerTrack 규칙 구문으로 작성됩니다. 자세한 내용은 규칙 및 필터링을 참조하세요. 사용자는 분 단위 정밀도로 임의의 기간을 지정할 수 있습니다. 다만, 응답은 지정한 maxResults 또는 31일 중 더 작은 값으로 제한되며, 다음 결과 세트를 페이지네이션하기 위한 next 토큰이 포함됩니다. 시간 매개변수를 지정하지 않으면 API는 최근 30일의 일치 데이터를 반환합니다. 엔터프라이즈 검색 API는 분 단위 정밀도의 저지연, 완전 충실도의 쿼리 기반 게시물 아카이브 액세스를 제공합니다. 게시물 데이터는 쿼리와 일치하는 가장 최근 게시물부터 시작하여 최신순(역순)으로 제공됩니다. 게시물은 게시 후 약 30초가 지나면 검색 API에서 조회할 수 있습니다. 이 검색 엔드포인트는 편집된 게시물 메타데이터를 제공합니다. 2022년 9월 29일 이후 생성된 게시물의 모든 객체에는, 게시물이 한 번도 편집되지 않았더라도, 게시물 편집 메타데이터가 포함됩니다. 게시물이 편집될 때마다 새로운 게시물 ID가 생성됩니다. 게시물의 편집 이력은 원래 ID부터 시작하는 게시물 ID 배열로 기록됩니다. 이 엔드포인트는 항상 가장 최신 편집본과 편집 이력을 함께 반환합니다. 게시물의 30분 편집 가능 시간 이후에 수집된 게시물은 최종 버전을 나타냅니다. 게시물 편집 메타데이터에 대해 더 알아보려면 Edit Posts 기본 사항 페이지를 참고하세요. 요청에는 API 응답당 반환할 최대 게시물 수를 지정하는 maxResults 매개변수가 포함됩니다. 쿼리와 연관된 게시물이 응답당 이 최대 결과 수를 초과할 경우, 응답에 next 토큰이 포함됩니다. 이 next 토큰은 후속 요청에서 쿼리와 연관된 전체 게시물 집합을 페이지 처리하는 데 사용됩니다. 이 엔터프라이즈 검색 API는 쿼리와 연관된 데이터 볼륨을 요청할 수 있도록 하는 counts 엔드포인트를 제공합니다. 

​
요청 유형

엔터프라이즈 검색 API는 두 가지 유형의 요청을 지원합니다:

​
검색 요청(데이터)

엔터프라이즈 검색 API에 대한 검색 요청은 지정된 기간 내에서 응답당 최대 500개의 결과를 반환하며, 추가 데이터를 위해 페이지네이션을 사용할 수 있습니다. maxResults 매개변수를 사용해 표시용 사례에는 더 작은 페이지 크기(필요 시 사용자가 더 많은 결과를 요청할 수 있도록)로, 대량 데이터 수집에는 더 큰 페이지 크기(최대 500)로 지정할 수 있습니다. 데이터는 최신순으로 제공되며, 제공 시점 기준으로 규정 준수를 충족합니다.

​
카운트 요청(게시물 카운트)

카운트 요청은 지정된 쿼리와 일치하는 활동이 요청된 기간 동안 얼마나 발생했는지를 보여 주는 과거 활동 카운트를 조회할 수 있게 합니다. 응답은 기본적으로 카운트의 히스토그램을 제공하며, 일/시간/분 단위로 버킷화됩니다(기본 버킷은 시간). 게시물이 게시된 후 상당한 시일(7일 이상)이 지나 발생하는 컴플라이언스 이벤트(예: 게시물 삭제)가 카운트 결과에 항상 반영되지 않을 수 있다는 점에 유의하세요. 따라서 동일한 쿼리에 대한 데이터 요청 결과와 카운트 지표가 항상 일치하지 않을 수 있습니다. 과금 안내: 데이터 및 카운트 엔드포인트에 대한 각 요청–페이지네이션 요청 포함–은 과금 대상 요청으로 집계됩니다. 따라서 단일 쿼리에 여러 결과 페이지가 있는 경우, X개의 결과 페이지를 순차적으로 조회하면 과금상 X개의 요청에 해당합니다.

​
사용 가능한 연산자

Enterprise 검색 API는 최대 2,048자의 규칙을 지원합니다. Enterprise 검색 API는 아래에 나열된 연산자를 지원합니다. 자세한 설명은 여기를 참고하세요. 
게시물 본문 매칭:관심 계정 매칭:게시물 속성:지리공간 연산자:
* 키워드
* “따옴표로 묶인 구문”
* “keyword1 keyword2”~N
* #
* @
* $
* url:
* lang:		* from:
* to:
* retweets_of:		* is:retweet

* has:mentions
* has:hashtags
* has:media
* has:videos
* has:images
* has:links
* has:symbols
* is:verified

* -is:nullcast (부정 전용 연산자)		* bounding_box:[west_long south_lat east_long north_lat]
* point_radius:[lon lat radius]
* has:geo
* place:
* place_country:
* has:profile_geo
* profile_country:
* profile_region:
* profile_locality:
메모: 연산자를 중첩하거나 결합해 쓰지 마세요. 예를 들어 “#cats”는 검색 API에서 cats로 해석됩니다. ‘lang:’ 연산자와 모든 ‘is:’ 및 ‘has:’ 연산자는 단독으로 사용할 수 없으며 반드시 다른 절과 함께 사용해야 합니다(예: @XDevelopers has:links).     검색 API는 토큰화/매칭 기능 때문에 제한된 연산자만 사용합니다. Enterprise 실시간 및 배치형 과거 API는 추가 연산자를 제공합니다. 자세한 내용은 여기를 참고하세요. 자세한 내용은 연산자 시작하기 가이드를 참고하세요.

​
데이터 가용성 / 중요 날짜

Full-Archive Search API를 사용할 때 X 플랫폼은 2006년부터 지속적으로 발전해 왔다는 점을 염두에 두세요. 새로운 기능이 추가되면서 기본 JSON 객체에도 메타데이터가 추가되었습니다. 따라서 검색 연산자가 매칭하는 게시물 속성이 언제 추가되었는지 이해하는 것이 중요합니다. 아래는 핵심 메타데이터 그룹의 주요 ‘도입일’입니다. 게시물 속성이 처음 도입된 시점에 대해 더 알아보려면 이 가이드를 참조하세요.  
  • 첫 게시물: 2006/3/21
  • 첫 기본형 리트윗: 2009/11/6
  • 첫 위치 태그가 포함된 게시물: 2009/11/19
  • 필터링을 위한 URL 최초 인덱싱: 2011/8/27
  • 확장된 URL 메타데이터(웹사이트 제목 및 설명): 2014/12/1
  • 프로필 위치 정보 강화 메타데이터 및 필터링: 2015/2/17

​
데이터 업데이트와 가변성

엔터프라이즈 검색 API에서는 게시물 내 일부 데이터가 가변적이며, 즉 초기 보관 후에도 업데이트되거나 변경될 수 있습니다. 이 가변 데이터는 다음의 두 범주로 나뉩니다:
  • 사용자 객체 메타데이터:
    • 사용자의 @handle(숫자 id는 절대 변경되지 않음)
    • 소개(바이오) 설명
    • 카운트: 상태, 팔로워, 친구, 즐겨찾기, 리스트
    • 프로필 위치
    • 시간대, 언어 등 기타 세부 정보
  • 게시물 통계 — 즉 사용자 행동으로 플랫폼에서 변경될 수 있는 항목(아래 예시):
    • 즐겨찾기 수
    • 리트윗 수
대부분의 경우 검색 API는 게시물 생성 시점이 아니라 쿼리 시점(query-time)에 플랫폼에 존재하는 데이터를 반환합니다. 그러나 선택 연산자(예: from, to, @, is:verified)를 사용하는 쿼리는 예외일 수 있습니다. 데이터는 당사 인덱스에서 정기적으로 업데이트되며, 최근 시점일수록 더 높은 빈도로 갱신됩니다. 그 결과, 일부 경우 반환되는 데이터가 X.com에 표시되는 현재 데이터와 정확히 일치하지 않을 수 있으나, 마지막으로 인덱싱된 시점의 데이터와 일치합니다. 주의: 이러한 불일치 문제는 연산자가 가변 데이터에 적용되는 쿼리에만 해당됩니다. 예를 들어 사용자 이름으로 필터링하는 경우가 이에 해당하며, 이러한 쿼리에서는 @handle 대신 사용자 숫자 id를 사용하는 것이 가장 좋은 해결책입니다.

​
단일 스레드 vs. 다중 스레드 요청

각 고객에게는 검색 엔드포인트에 대한 고정된 속도 제한이 있습니다. 전체 아카이브 검색의 기본 분당 속도 제한은 분당 120건의 요청으로, 초당 평균 2건의 쿼리(QPS)에 해당합니다. 이 평균 QPS는 이론적으로 매초 API에 2건의 요청을 보낼 수 있음을 의미합니다. 제품의 페이지네이션 기능을 고려하면, 1년짜리 쿼리에 연간 고르게 분포된 100만 개의 게시물이 연결되어 있는 경우, 모든 데이터를 받기 위해(‘maxResults’가 500이라고 가정) 2,000건이 넘는 요청이 필요합니다. 응답당 2초가 걸린다고 가정하면, 단일 스레드로 순차적으로 모든 데이터를 가져오는 데 4,000초(약 1시간 조금 초과)가 걸립니다(이전 응답의 “next” 토큰을 사용해 초당 1건 요청). 나쁘지 않습니다! 이제 데이터를 수신하기 위해 12개의 병렬 스레드를 사용하는 상황을 생각해 보세요. 100만 개의 게시물이 1년 동안 고르게 분포되어 있다고 가정하면, 요청을 12개의 병렬 스레드(멀티 스레드)로 분할해 단일 “작업”에 대해 초당 속도 제한을 더 활용할 수 있습니다. 즉, 관심 있는 각 월별로 스레드 하나씩 실행하면 데이터를 12배 더 빠르게(~6분) 가져올 수 있습니다. 이 다중 스레드 예시는 counts 엔드포인트에도 동일하게 적용됩니다. 예를 들어, 2년 기간에 대한 게시물 counts를 받고자 한다면, 단일 스레드 요청으로 한 번에 31일씩 counts를 페이지네이션하며 거슬러 올라갈 수 있습니다. 응답당 2초가 걸린다고 가정하면, 전체 counts 세트를 가져오기 위해 24건의 API 요청을 수행하는 데 약 48초가 걸립니다. 그러나 동시에 여러 한 달 단위 요청을 보낼 수도 있습니다. 초당 12건의 요청을 보낼 경우, 전체 counts 세트는 약 2초 만에 받아볼 수 있습니다.

​
재시도 로직

Enterprise 검색 API에서 503 오류가 발생한 경우, 일시적인 문제일 가능성이 높으며 잠시 후 요청을 다시 시도하면 해결될 수 있습니다. 요청이 연속으로 4번 실패했고 각 실패 사이에 최소 10분을 기다렸다면, 다음 단계를 따라 문제를 해결하세요:
  • 요청이 포함하는 시간 범위를 줄인 뒤 다시 시도하세요. 실패할 경우 6시간 구간까지 단계적으로 줄여 보세요.
  • 많은 용어를 OR로 결합하고 있다면, 이를 별도의 규칙으로 분리하여 각각 개별적으로 재시도하세요.
  • 규칙에서 제외 조건을 많이 사용 중이라면, 부정 조건(negated terms)의 수를 줄이고 다시 시도하세요.

​
빠른 시작

​
엔터프라이즈 Search Posts: 30-Day API 시작하기

엔터프라이즈 Search Posts: 30-Day API는 최근 30일 이내에 게시된 게시물을 제공합니다. 게시물은 요청에 지정한 쿼리를 기준으로 매칭되어 반환됩니다. 쿼리는 반환될 게시물이 어떤 내용을 포함해야 하는지 정의하는 규칙입니다. 이 튜토리얼에서는 X 계정 @XDevelopers에서 영어로 작성된 게시물을 검색합니다. 응답으로 받는 게시물은 전체 게시물 페이로드를 제공하는 data 형식이거나, 매칭된 게시물의 수치 집계 데이터를 제공하는 counts 형식일 수 있습니다. 우리는 cURL을 사용해 data 및 counts 엔드포인트에 요청을 보냅니다. 다음이 필요합니다:

​
데이터 엔드포인트에 액세스하기

데이터 엔드포인트는 일치한 게시물의 전체 게시물 페이로드를 제공합니다. from: 및 lang: 연산자를 사용해 @XDevelopers에서 작성된 영어 게시물을 찾아보겠습니다. 더 많은 연산자는 여기를 클릭.
  • cURL
  • cURL example
cURL은 URL 구문을 사용하여 파일을 가져오거나 전송하는 명령줄 도구입니다.아래 항목을 수정한 후 다음 cURL 요청을 명령줄에 복사하세요:
  • Username <USERNAME> 예: email@domain.com
  • Account name <ACCOUNT-NAME> 예: john-doe
  • Label <LABEL> 예: prod
  • fromDate 및 toDate 예: "fromDate":"201811010000", "toDate":"201811122359"
요청을 전송하면 비밀번호 입력을 요청받습니다.
curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/30day/accounts/<ACCOUNT-NAME>/<LABEL>.json" -d '{"query":"from:TwitterDev lang:en","maxResults":"500","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>"}'

​
데이터 엔드포인트 응답 페이로드

API 요청에 대한 페이로드는 아래와 같이 JSON 형식으로 반환됩니다. 
{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relevant conv…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
			"truncated": false,
			"in_reply_to_status_id": null,
			"in_reply_to_status_id_str": null,
			"in_reply_to_user_id": null,
			"in_reply_to_user_id_str": null,
			"in_reply_to_screen_name": null,
			"user": {
				"id": 2244994945,
				"id_str": "2244994945",
				"name": "Twitter Dev",
				"screen_name": "TwitterDev",
				"location": "Internet",
				"url": "https:\/\/developer.x.com\/",
				"description": "X 플랫폼 뉴스, 업데이트 및 이벤트에 대한 공식 소스입니다. 기술 지원이 필요하신가요? https:\/\/devcommunity.com\/ 을 방문하세요 ⌨️ #TapIntoTwitter",
				"translator_type": "null",
				"protected": false,
				"verified": true,
				"followers_count": 503828,
				"friends_count": 1477,
				"listed_count": 1437,
				"favourites_count": 2199,
				"statuses_count": 3380,
				"created_at": "Sat Dec 14 04:35:55 +0000 2013",
				"utc_offset": null,
				"time_zone": null,
				"geo_enabled": true,
				"lang": "en",
				"contributors_enabled": false,
				"is_translator": false,
				"profile_background_color": "null",
				"profile_background_image_url": "null",
				"profile_background_image_url_https": "null",
				"profile_background_tile": null,
				"profile_link_color": "null",
				"profile_sidebar_border_color": "null",
				"profile_sidebar_fill_color": "null",
				"profile_text_color": "null",
				"profile_use_background_image": null,
				"profile_image_url": "null",
				"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/880136122604507136\/xHrnqf1T_normal.jpg",
				"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/2244994945\/1498675817",
				"default_profile": false,
				"default_profile_image": false,
				"following": null,
				"follow_request_sent": null,
				"notifications": null
			},
			"geo": null,
			"coordinates": null,
			"place": null,
			"contributors": null,
			"retweeted_status": {
				"created_at": "Tue Oct 30 21:30:25 +0000 2018",
				"id": 1057384253116289025,
				"id_str": "1057384253116289025",
				"text": "\"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relev… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
				"truncated": true,
				"in_reply_to_status_id": null,
				"in_reply_to_status_id_str": null,
				"in_reply_to_user_id": null,
				"in_reply_to_user_id_str": null,
				"in_reply_to_screen_name": null,
				"user": {
					"id": 175187944,
					"id_str": "175187944",
					"name": "Tyler Singletary",
					"screen_name": "harmophone",
					"location": "San Francisco, CA",
					"url": "http:\/\/medium.com\/@harmophone",
					"description": "@Tagboard의 제품 담당 수석 부사장. @Klout 및 @LithiumTech에서 데이터, 비즈니스 및 제품 업무 수행; @BBI 이사회 멤버; @Insightpool 자문위원. 세계 최악의 화이트보드 사용자.",
					"translator_type": "null",
					"protected": false,
					"verified": false,
					"followers_count": 1982,
					"friends_count": 1877,
					"listed_count": 245,
					"favourites_count": 23743,
					"statuses_count": 12708,
					"created_at": "Thu Aug 05 22:59:29 +0000 2010",
					"utc_offset": null,
					"time_zone": null,
					"geo_enabled": false,
					"lang": "en",
					"contributors_enabled": false,
					"is_translator": false,
					"profile_background_color": "null",
					"profile_background_image_url": "null",
					"profile_background_image_url_https": "null",
					"profile_background_tile": null,
					"profile_link_color": "null",
					"profile_sidebar_border_color": "null",
					"profile_sidebar_fill_color": "null",
					"profile_text_color": "null",
					"profile_use_background_image": null,
					"profile_image_url": "null",
					"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/719985428632240128\/WYFHcK-m_normal.jpg",
					"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/175187944\/1398653841",
					"default_profile": false,
					"default_profile_image": false,
					"following": null,
					"follow_request_sent": null,
					"notifications": null
				},
				"geo": null,
				"coordinates": null,
				"place": null,
				"contributors": null,
				"is_quote_status": false,
				"extended_tweet": {
					"full_text": "\"Tagboard, Twitter 및 TEGNA의 협업을 통한 혁신적인 크라우드소싱은 지역적으로 관련성 있는 대화를 실시간으로 발굴하고 유권자들이 토론 중에 질문할 수 있도록 합니다,\"  -- @adamostrow, @TEGNA\n자세히 알아보기: https:\/\/t.co\/ivAFtanfje",
					"display_text_range": [
						0,
						259
					],
					"entities": {
						"hashtags": [],
						"urls": [
							{
								"url": "https:\/\/t.co\/ivAFtanfje",
								"expanded_url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
								"display_url": "blog.tagboard.com\/twitter-and-ta…",
								"unwound": {
									"url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
									"status": 200,
									"title": "Twitter와 Tagboard가 협력하여 Tagboard를 통해 뉴스 매체에 최고의 선거 콘텐츠 제공…",
									"description": "Tyler Singletary, Tagboard 제품 책임자"
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "Adam Ostrow",
								"id": 5695942,
								"id_str": "5695942",
								"indices": [
									204,
									215
								]
							},
							{
								"screen_name": "TEGNA",
								"name": "TEGNA",
								"id": 34123003,
								"id_str": "34123003",
								"indices": [
									217,
									223
								]
							}
						],
						"symbols": []
					}
				},
				"quote_count": 0,
				"reply_count": 1,
				"retweet_count": 6,
				"favorite_count": 19,
				"entities": {
					"hashtags": [],
					"urls": [
						{
							"url": "https:\/\/t.co\/w46U5TRTzQ",
							"expanded_url": "https:\/\/twitter.com\/i\/web\/status\/1057384253116289025",
							"display_url": "twitter.com\/i\/web\/status\/1…",
							"indices": [
								117,
								140
							]
						}
					],
					"user_mentions": [],
					"symbols": []
				},
				"favorited": false,
				"retweeted": false,
				"possibly_sensitive": false,
				"filter_level": "low",
				"lang": "en"
			},
			"is_quote_status": false,
			"quote_count": 0,
			"reply_count": 0,
			"retweet_count": 0,
			"favorite_count": 0,
			"entities": {
				"hashtags": [],
				"urls": [],
				"user_mentions": [
					{
						"screen_name": "harmophone",
						"name": "Tyler Singletary",
						"id": 175187944,
						"id_str": "175187944",
						"indices": [
							3,
							14
						]
					}
				],
				"symbols": []
			},
			"favorited": false,
			"retweeted": false,
			"filter_level": "low",
			"lang": "en",
			"matching_rules": [
				{
					"tag": null
				}
			]
		}
	],
	"requestParameters": {
		"maxResults": 100,
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

​
counts 엔드포인트에 액세스하기

counts 엔드포인트를 사용해 day 기준으로 그룹화된, @XDevelopers 계정에서 영어로 작성된 게시물 수를 조회합니다.
  • cURL
  • cURL example
cURL은 URL 구문을 사용하여 파일을 가져오거나 전송하는 명령줄 도구입니다.아래 항목을 수정한 뒤 다음 cURL 요청을 명령줄에 복사해 실행하세요:
  • Username <USERNAME> 예: email@domain.com
  • Account name <ACCOUNT-NAME> 예: john-doe
  • Label <LABEL> 예: prod
  • fromDate 및 toDate 예: "fromDate":"201811010000", "toDate":"201811122359"
요청을 전송하면 비밀번호 입력을 요구받습니다.
curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/30day/accounts/<ACCOUNT-NAME>/<LABEL>/counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>","bucket":"day"}'

​
Counts 엔드포인트 응답 페이로드

API 요청에 대한 응답 페이로드는 아래 예시처럼 JSON 형식으로 제공됩니다. 
{
	"results": [
		{
			"timePeriod": "201811010000",
			"count": 0
		},
		{
			"timePeriod": "201811020000",
			"count": 1
		},
		{
			"timePeriod": "201811030000",
			"count": 0
		},
		{
			"timePeriod": "201811040000",
			"count": 0
		},
		{
			"timePeriod": "201811050000",
			"count": 0
		}
	],
	"totalCount": 1,
	"requestParameters": {
		"bucket": "day",
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}
잘하셨습니다! 이제 엔터프라이즈용 Search Posts: 30-Day API에 성공적으로 접근했습니다.
참고 자료

​
엔터프라이즈 Search Posts: Full-Archive API 시작하기

엔터프라이즈 Search Posts: Full-Archive API는 2006년 첫 게시물부터의 게시물을 제공합니다. 게시물은 요청에 지정한 쿼리에 따라 매칭되어 반환됩니다. 쿼리는 반환받을 게시물이 포함해야 할 내용을 정의하는 규칙입니다. 이 튜토리얼에서는 X 계정 @XDevelopers에서 영어로 게시된 게시물을 검색합니다. 페이로드로 반환되는 게시물은 전체 게시물 페이로드를 제공하는 data 형식이거나, 매칭된 게시물의 수치 집계 데이터를 제공하는 counts 형식일 수 있습니다. 우리는 data 및 counts 엔드포인트에 요청을 보내기 위해 cURL을 사용합니다. 다음이 필요합니다:

​
데이터 엔드포인트에 액세스하기

데이터 엔드포인트는 조건과 일치한 게시물의 전체 게시물 페이로드를 제공합니다. from: 및 lang: 연산자를 사용해 영어로 작성된 @XDevelopers의 게시물을 찾겠습니다. 더 많은 연산자는 여기를 클릭하세요.
  • cURL
  • cURL example
cURL은 URL 구문을 사용해 파일을 가져오거나 전송하는 명령줄 도구입니다.아래 cURL 요청에서 다음 항목을 변경한 뒤 명령줄에 복사하세요:
  • 사용자 이름 <USERNAME> 예: email@domain.com
  • 계정 이름 <ACCOUNT-NAME> 예: john-doe
  • 레이블 <LABEL> 예: prod
  • fromDate 및 toDate 예: "fromDate":"201802010000", "toDate":"201802282359"
요청을 전송하면 비밀번호 입력을 요구하는 프롬프트가 표시됩니다.
curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/fullarchive/accounts/<ACCOUNT-NAME>/<LABEL>.json" -d '{"query":"from:TwitterDev lang:en","maxResults":"500","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>"}'
데이터 엔드포인트 응답 페이로드
API 요청의 응답 페이로드는 아래 예시처럼 JSON 형식으로 반환됩니다. 
{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"Tagboard, Twitter 및 TEGNA의 협업으로 가능해진 혁신적인 크라우드소싱이 지역사회와 관련된 대화를 실시간으로 드러내고 있습니다…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter 웹 클라이언트<\/a>",
			"truncated": false,
			"in_reply_to_status_id": null,
			"in_reply_to_status_id_str": null,
			"in_reply_to_user_id": null,
			"in_reply_to_user_id_str": null,
			"in_reply_to_screen_name": null,
			"user": {
				"id": 2244994945,
				"id_str": "2244994945",
				"name": "Twitter Dev",
				"screen_name": "TwitterDev",
				"location": "인터넷",
				"url": "https:\/\/developer.x.com\/",
				"description": "Twitter Platform 소식, 업데이트 및 이벤트에 대한 공식 출처입니다. 기술 지원이 필요하신가요? https:\/\/devcommunity.com\/ ⌨️ #TapIntoTwitter 방문",
				"translator_type": "null",
				"protected": false,
				"verified": true,
				"followers_count": 503828,
				"friends_count": 1477,
				"listed_count": 1437,
				"favourites_count": 2199,
				"statuses_count": 3380,
				"created_at": "Sat Dec 14 04:35:55 +0000 2013",
				"utc_offset": null,
				"time_zone": null,
				"geo_enabled": true,
				"lang": "en",
				"contributors_enabled": false,
				"is_translator": false,
				"profile_background_color": "null",
				"profile_background_image_url": "null",
				"profile_background_image_url_https": "null",
				"profile_background_tile": null,
				"profile_link_color": "null",
				"profile_sidebar_border_color": "null",
				"profile_sidebar_fill_color": "null",
				"profile_text_color": "null",
				"profile_use_background_image": null,
				"profile_image_url": "null",
				"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/880136122604507136\/xHrnqf1T_normal.jpg",
				"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/2244994945\/1498675817",
				"default_profile": false,
				"default_profile_image": false,
				"following": null,
				"follow_request_sent": null,
				"notifications": null
			},
			"geo": null,
			"coordinates": null,
			"place": null,
			"contributors": null,
			"retweeted_status": {
				"created_at": "Tue Oct 30 21:30:25 +0000 2018",
				"id": 1057384253116289025,
				"id_str": "1057384253116289025",
				"text": "\"Tagboard, Twitter 및 TEGNA의 협업으로 가능해진 혁신적인 크라우드소싱이 지역사회와 관련된 대화를 실시간으로 드러내고 있습… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter 웹 클라이언트<\/a>",
				"truncated": true,
				"in_reply_to_status_id": null,
				"in_reply_to_status_id_str": null,
				"in_reply_to_user_id": null,
				"in_reply_to_user_id_str": null,
				"in_reply_to_screen_name": null,
				"user": {
					"id": 175187944,
					"id_str": "175187944",
					"name": "Tyler Singletary",
					"screen_name": "harmophone",
					"location": "San Francisco, CA",
					"url": "http:\/\/medium.com\/@harmophone",
					"description": "SVP Product at @Tagboard. Did some Data, biz, and product @Klout & for @LithiumTech; @BBI board member; @Insightpool advisor. World's worst whiteboarder.",
					"translator_type": "null",
					"protected": false,
					"verified": false,
					"followers_count": 1982,
					"friends_count": 1877,
					"listed_count": 245,
					"favourites_count": 23743,
					"statuses_count": 12708,
					"created_at": "Thu Aug 05 22:59:29 +0000 2010",
					"utc_offset": null,
					"time_zone": null,
					"geo_enabled": false,
					"lang": "en",
					"contributors_enabled": false,
					"is_translator": false,
					"profile_background_color": "null",
					"profile_background_image_url": "null",
					"profile_background_image_url_https": "null",
					"profile_background_tile": null,
					"profile_link_color": "null",
					"profile_sidebar_border_color": "null",
					"profile_sidebar_fill_color": "null",
					"profile_text_color": "null",
					"profile_use_background_image": null,
					"profile_image_url": "null",
					"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/719985428632240128\/WYFHcK-m_normal.jpg",
					"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/175187944\/1398653841",
					"default_profile": false,
					"default_profile_image": false,
					"following": null,
					"follow_request_sent": null,
					"notifications": null
				},
				"geo": null,
				"coordinates": null,
				"place": null,
				"contributors": null,
				"is_quote_status": false,
				"extended_tweet": {
					"full_text": "\"Tagboard, Twitter 및 TEGNA의 협업으로 가능해진 혁신적인 크라우드소싱이 지역사회와 관련된 대화를 실시간으로 드러내고, 토론 중 유권자들이 질문할 수 있도록 합니다.”  -- @adamostrow, @TEGNA\n자세히 알아보기: https:\/\/t.co\/ivAFtanfje",
					"display_text_range": [
						0,
						259
					],
					"entities": {
						"hashtags": [],
						"urls": [
							{
								"url": "https:\/\/t.co\/ivAFtanfje",
								"expanded_url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
								"display_url": "blog.tagboard.com\/twitter-and-ta…",
								"unwound": {
									"url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
									"status": 200,
									"title": "Twitter와 Tagboard가 협업해 뉴스 매체에 최고의 선거 콘텐츠를 제공…",
									"description": "Tyler Singletary, 제품 총괄, Tagboard",
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "Adam Ostrow",
								"id": 5695942,
								"id_str": "5695942",
								"indices": [
									204,
									215
								]
							},
							{
								"screen_name": "TEGNA",
								"name": "TEGNA",
								"id": 34123003,
								"id_str": "34123003",
								"indices": [
									217,
									223
								]
							}
						],
						"symbols": []
					}
				},
				"quote_count": 0,
				"reply_count": 1,
				"retweet_count": 6,
				"favorite_count": 19,
				"entities": {
					"hashtags": [],
					"urls": [
						{
							"url": "https:\/\/t.co\/w46U5TRTzQ",
							"expanded_url": "https:\/\/twitter.com\/i\/web\/status\/1057384253116289025",
							"display_url": "twitter.com\/i\/web\/status\/1…",
							"indices": [
								117,
								140
							]
						}
					],
					"user_mentions": [],
					"symbols": []
				},
				"favorited": false,
				"retweeted": false,
				"possibly_sensitive": false,
				"filter_level": "low",
				"lang": "en",
			},
			"is_quote_status": false,
			"quote_count": 0,
			"reply_count": 0,
			"retweet_count": 0,
			"favorite_count": 0,
			"entities": {
				"hashtags": [],
				"urls": [],
				"user_mentions": [
					{
						"screen_name": "harmophone",
						"name": "Tyler Singletary",
						"id": 175187944,
						"id_str": "175187944",
						"indices": [
							3,
							14
						]
					}
				],
				"symbols": []
			},
			"favorited": false,
			"retweeted": false,
			"filter_level": "low",
			"lang": "en",
			"matching_rules": [
				{
					"tag": null
				}
			]
		}
	],
	"requestParameters": {
		"maxResults": 100,
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

​
counts 엔드포인트 사용하기

counts 엔드포인트를 사용해 @XDevelopers 계정에서 영어로 작성된 게시물 수를 day 단위로 집계해 가져옵니다.
  • cURL
  • cURL example
cURL은 URL 구문을 사용해 파일을 가져오거나 전송하는 명령줄 도구입니다.아래의 cURL 요청에서 다음 항목을 수정한 뒤 명령줄에 복사하세요:
  • Username <USERNAME> 예: email@domain.com
  • Account name <ACCOUNT-NAME> 예: john-doe
  • Label <LABEL> 예: prod
  • fromDate 및 toDate 예: "fromDate":"201802010000", "toDate":"201802282359"
요청을 전송하면 비밀번호 입력을 요청받습니다.
curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/fullarchive/accounts/<ACCOUNT-NAME>/<LABEL>/counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>","bucket":"day"}'

​
Counts 엔드포인트 응답 페이로드

API 요청에 대한 페이로드는 아래와 같이 JSON 형식으로 반환됩니다. 
{
	"results": [
		{
			"timePeriod": "201811010000",
			"count": 0
		},
		{
			"timePeriod": "201811020000",
			"count": 1
		},
		{
			"timePeriod": "201811030000",
			"count": 0
		},
		{
			"timePeriod": "201811040000",
			"count": 0
		},
		{
			"timePeriod": "201811050000",
			"count": 0
		}
	],
	"totalCount": 1,
	"requestParameters": {
		"bucket": "day",
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}
잘하셨습니다! 이제 엔터프라이즈 Search Posts: Full-Archive API에 성공적으로 접근하셨습니다.
참고 문서

​
안내서

​
검색 쿼리 만들기

​
엔터프라이즈 연산자

아래는 X의 엔터프라이즈 검색 API에서 지원되는 모든 연산자 목록입니다:
  • Enterprise 30일 검색 API
  • Enterprise 전체 아카이브 검색 API
제품별로 사용 가능한 연산자를 나란히 비교하려면 여기를 참조하세요.
Operator설명
keyword게시물의 본문 또는 URL 내에서 토큰화된 키워드를 일치시킵니다. 이는 토큰화 일치로, 키워드 문자열이 게시물 본문의 토큰화된 텍스트와 비교됩니다. 토큰화는 구두점, 기호, 분리자 유니코드 기본 평면 문자에 기반합니다. 예를 들어, 텍스트 “I like coca-cola”가 있는 게시물은 다음 토큰으로 분리됩니다: I, like, coca, cola. 그런 다음 이 토큰들을 규칙에 사용한 키워드 문자열과 비교합니다. 구두점(예: coca-cola), 기호 또는 분리자를 포함하는 문자열을 일치시키려면 아래에 설명된 것처럼 따옴표로 감싼 정확한 일치를 사용해야 합니다.

참고: Search API에서는 악센트 및 특수 문자가 표준 라틴 문자로 정규화되며, 이는 외국어에서 의미가 바뀌거나 예기치 않은 결과를 반환할 수 있습니다:
예: “músic”은 “music”과 상호 일치합니다.
예: 스페인어의 흔한 문구 “Feliz Año Nuevo!”는 “Feliz Ano Nuevo”로 색인화되어 문구의 의미가 바뀝니다.

참고: 이 연산자는 게시물 내의 URL과 풀린 URL 모두에 대해 일치합니다.
emoji게시물 본문 내의 이모지를 일치시킵니다. 이모지는 토큰화 일치로, 사용한 이모지가 게시물 본문의 토큰화된 텍스트와 비교됩니다. 토큰화는 구두점, 기호/이모지, 분리자 유니코드 기본 평면 문자에 기반합니다. 예를 들어, 텍스트 “I like ”가 있는 게시물은 다음 토큰으로 분리됩니다: I, like, . 그런 다음 이 토큰들을 규칙에서 사용한 이모지와 비교합니다. 이모지에 변형이 있는 경우, 규칙에 추가할 때 따옴표를 사용해야 합니다.
”exact phrase match”게시물의 본문 또는 URL 내에서 토큰화되고 순서가 유지된 구를 일치시킵니다. 이는 토큰화 일치로, 키워드 문자열이 게시물 본문의 토큰화된 텍스트와 비교됩니다. 토큰화는 구두점, 기호, 분리자 유니코드 기본 평면 문자에 기반합니다.

참고: 구두점은 토큰화되지 않으며 공백으로 처리됩니다.
예: 따옴표로 감싼 “#hashtag”는 “hashtag”와는 일치하지만 #hashtag와는 일치하지 않습니다(실제 해시태그와 일치시키려면 따옴표 없이 해시태그 # 연산자를 사용).
예: 따옴표로 감싼 “cashtag”는“cashtag”와는일치하지만cashtag”는 “cashtag”와는 일치하지만 cashtag와는 일치하지 않습니다(실제 캐시태그와 일치시키려면 따옴표 없이 캐시태그 $ 연산자를 사용).
예: “Love Snow”는 “#love #snow”와 일치합니다.
예: “#Love #Snow”는 “love snow”와 일치합니다.

참고: 이 연산자는 게시물 내의 URL과 풀린 URL 모두에 대해 일치합니다.
”keyword1 keyword2”~N일반적으로 근접 연산자라고 하며, 키워드들이 서로 N토큰 이내에 있는 게시물을 일치시킵니다.

키워드의 순서가 반대인 경우에는 서로 N-2토큰보다 멀어질 수 없습니다. 따옴표 안에 임의 개수의 키워드를 포함할 수 있습니다. N은 6을 초과할 수 없습니다.

이 연산자는 enterprise 검색 API에서만 사용할 수 있습니다.
from:특정 사용자의 모든 게시물을 일치시킵니다.
값은 사용자의 X 숫자 계정 ID 또는 사용자명(@ 문자는 제외)이어야 합니다. 숫자 X 계정 ID를 조회하는 방법은 여기 또는 여기를 참조하세요.
to:특정 사용자에게 대한 답글인 모든 게시물을 일치시킵니다.

값은 사용자의 숫자 계정 ID 또는 사용자명(@ 문자는 제외)이어야 합니다. 숫자 X 계정 ID를 조회하는 방법은 여기를 참조하세요.
url:게시물의 확장된 URL에 대해 토큰화된(키워드/구) 일치를 수행합니다(url_contains와 유사). 구두점이나 특수 문자를 포함하는 토큰 및 구는 큰따옴표로 감싸야 합니다. 예: url:“/developer”. 특정 프로토콜로 일치시키려면(일반적으로 권장하지 않음) 큰따옴표로 감싸세요: url:“https://developer.x.com”.
참고: PowerTrack 또는 Historical PowerTrack을 사용할 때 이 연산자는 인용 게시물의 원본 게시물에 포함된 URL에도 일치합니다. 예를 들어, 규칙에 url:“developer.x.com”이 포함되어 있고 어떤 게시물이 해당 URL을 포함한다면, 그 게시물을 인용한 모든 인용 트윗도 결과에 포함됩니다. 이는 Search API를 사용할 때에는 해당되지 않습니다.
#지정한 해시태그가 있는 모든 게시물을 일치시킵니다.

이 연산자는 토큰화 일치가 아닌 정확한 일치를 수행하므로, 규칙 “2016”은 정확히 “2016” 해시태그가 있는 게시물과는 일치하지만 “2016election” 해시태그가 있는 게시물과는 일치하지 않습니다.

참고: 해시태그 연산자는 해시태그를 본문에서 추출하려 하기보다 X의 엔터티 추출을 활용하여 해시태그를 일치시킵니다. X 엔터티의 JSON 속성에 대한 자세한 내용은 여기를 참조하세요.
@지정한 사용자명을 언급한 모든 게시물을 일치시킵니다.
to: 연산자는 @mention 연산자의 부분 집합 결과를 반환합니다.
$지정한 ‘캐시태그’(토큰의 첫 글자가 ‘$’인 경우)가 포함된 모든 게시물을 일치시킵니다.

캐시태그 연산자는 본문에서 캐시태그를 추출하려 하기보다 X의 ‘symbols’ 엔터티 추출을 활용하여 캐시태그를 일치시킵니다. 자세한 내용은 여기를 참조하세요.

이 연산자는 enterprise 검색 API에서만 사용할 수 있습니다.

retweets_of:사용 가능한 별칭: retweets_of_user:
지정한 사용자의 리트윗인 게시물을 일치시킵니다. 사용자명과 숫자 X 계정 ID(게시물 상태 ID 아님) 모두를 허용합니다. 숫자 X 계정 ID를 조회하는 방법은 여기를 참조하세요.
lang:특정 언어로 X에 의해 분류된 게시물을 일치시킵니다(게시물이 분류된 경우에 한함). 각 게시물은 현재 한 가지 언어로만 분류되므로 여러 언어를 AND로 결합하면 결과가 나오지 않습니다.

참고: 언어 분류를 할 수 없는 경우 제공되는 결과는 ‘und’(정의되지 않음)입니다.

아래 목록은 현재 지원되는 언어와 해당 BCP 47 언어 식별자를 나타냅니다:
암하라어: am독일어: de말라얄람어: ml슬로바키아어: sk
아랍어: ar그리스어: el디베히어: dv슬로베니아어: sl
아르메니아어: hy구자라트어: gu마라티어: mr소라니 쿠르드어: ckb
바스크어: eu아이티 크리올어: ht네팔어: ne스페인어: es
벵골어: bn히브리어: iw노르웨이어: no스웨덴어: sv
보스니아어: bs힌디어: hi오리아어: or타갈로그어: tl
불가리아어: bg힌디어(라틴 문자 표기): hi-Latn펀자브어: pa타밀어: ta
미얀마어: my헝가리어: hu파슈토어: ps텔루구어: te
크로아티아어: hr아이슬란드어: is페르시아어: fa태국어: th
카탈루냐어: ca인도네시아어: in폴란드어: pl티베트어: bo
체코어: cs이탈리아어: it포르투갈어: pt번체 중국어: zh-TW
덴마크어: da일본어: ja루마니아어: ro터키어: tr
네덜란드어: nl칸나다어: kn러시아어: ru우크라이나어: uk
영어: en크메르어: km세르비아어: sr우르두어: ur
에스토니아어: et한국어: ko간체 중국어: zh-CN위구르어: ug
핀란드어: fi라오어: lo신디어: sd베트남어: vi
프랑스어: fr라트비아어: lv싱할라어: si웨일스어: cy
조지아어: ka리투아니아어: lt
place:지정된 위치 또는 X place ID로 태그된 게시물과 일치합니다(예시 참조). 여러 단어로 이루어진 장소명(“New York City”, “Palo Alto”)은 큰따옴표로 감싸야 합니다.

참고: X place ID를 얻는 방법은 공개 API 엔드포인트 GET geo/search를 확인하세요.

참고: 이 연산자는 리포스트에는 일치하지 않습니다. 리포스트의 장소 정보는 원본 게시물에 연결되기 때문입니다. 또한 인용 리포스트의 원본 게시물에 연결된 장소에도 일치하지 않습니다.
place_country:태그된 place에 연계된 국가 코드가 지정된 ISO 알파-2 문자 코드와 일치하는 게시물과 매칭됩니다.

유효한 ISO 코드는 여기에서 확인할 수 있습니다: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

참고: 이 연산자는 리포스트에는 일치하지 않습니다. 리포스트의 장소 정보는 원본 게시물에 연결되기 때문입니다. 또한 인용 리포스트의 원본 게시물에 연결된 장소에도 일치하지 않습니다.
point_radius:[lon lat radius]게시물에 존재할 경우 해당 게시물의 정확한 위치(x, y)에 대해, 그리고 X에서는 “Place” 지오 폴리곤에 대해 매칭되며, 해당 Place가 정의된 영역 내에 완전히 포함된 경우에 일치합니다.

* 지원되는 반지름 단위는 마일(mi)과 킬로미터(km)입니다.
* 반지름은 25mi 미만이어야 합니다.
* 경도는 ±180 범위입니다.
* 위도는 ±90 범위입니다.
* 모든 좌표는 십진 도(degree)입니다.
* 규칙 인수는 대괄호로 묶고, 공백으로 구분합니다.

참고: 이 연산자는 리포스트에는 일치하지 않습니다. 리포스트의 장소 정보는 원본 게시물에 연결되기 때문입니다. 또한 인용 리포스트의 원본 게시물에 연결된 장소에도 일치하지 않습니다.
bounding_box:[west_long south_lat east_long north_lat]사용 가능한 별칭: geo_bounding_box:

게시물에 존재할 경우 해당 게시물의 정확한 위치(경도, 위도)에 대해, 그리고 X에서는 “Place” 지오 폴리곤에 대해 매칭되며, 해당 Place가 정의된 영역 내에 완전히 포함된 경우에 일치합니다.

* west_long과 south_lat는 경계 상자의 남서쪽 꼭짓점을 나타내며, west_long은 해당 지점의 경도, south_lat는 위도입니다.
* east_long과 north_lat는 경계 상자의 북동쪽 꼭짓점을 나타내며, east_long은 해당 지점의 경도, north_lat는 위도입니다.
* 경계 상자의 가로와 세로 길이는 25mi 미만이어야 합니다.
* 경도는 ±180 범위입니다.
* 위도는 ±90 범위입니다.
* 모든 좌표는 십진 도(degree)입니다.
* 규칙 인수는 대괄호로 묶고, 공백으로 구분합니다.
참고: 이 연산자는 리포스트에는 일치하지 않습니다. 리포스트의 장소 정보는 원본 게시물에 연결되기 때문입니다. 또한 인용 리포스트의 원본 게시물에 연결된 장소에도 일치하지 않습니다.
profile_country:Profile Geo 보강의 “address” 객체 중 “countryCode” 필드와 정확히 일치합니다.
ISO-3166-1-alpha-2 사양을 기반으로 한 표준화된 두 글자 국가 코드 집합을 사용합니다. 간결성을 위해 “address” 객체의 “country” 필드용 연산자 대신 이 연산자가 제공됩니다.
profile_region:Profile Geo 보강의 “address” 객체 중 “region” 필드와 일치합니다.

정확한 전체 문자열 일치입니다. 백슬래시로 문자를 이스케이프할 필요가 없습니다. 예를 들어 슬래시가 포함된 값을 매칭하려면 “one/two”를 사용하고 “one/two”는 사용하지 마세요. 공백이나 구두점이 포함된 하위 문자열을 매칭하려면 큰따옴표를 사용하세요.
profile_locality:Profile Geo 보강의 “address” 객체 중 “locality” 필드와 일치합니다.

정확한 전체 문자열 일치입니다. 백슬래시로 문자를 이스케이프할 필요가 없습니다. 예를 들어 슬래시가 포함된 값을 매칭하려면 “one/two”를 사용하고 “one/two”는 사용하지 마세요. 공백이나 구두점이 포함된 하위 문자열을 매칭하려면 큰따옴표를 사용하세요.
참고: Search API 사용 시 is: 및 has: 연산자는 단독으로 사용할 수 없으며 반드시 다른 절과 함께 사용해야 합니다.예: @XDeevelopers has:links
has:geoX에서 제공하는 게시물별 지리 위치 데이터가 있는 게시물을 매칭합니다. 이는 “geo” 위도·경도 좌표이거나, 표시 이름, 지오 폴리곤 및 기타 필드를 포함하는 X “Place” 형태의 “location”일 수 있습니다.



참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
has:profile_geo사용 가능한 별칭: has:derived_user_geo

실제 값과 관계없이 Profile Geo 메타데이터가 있는 게시물을 매칭합니다.


참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
has:links이 연산자는 메시지 본문에 링크가 포함된 게시물을 매칭합니다.


참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
is:retweet규칙과 일치하는 명시적 리트윗만 전달합니다. 또한 부정을 사용하여 규칙과 일치하는 리트윗을 제외하고 원본 콘텐츠만 전달할 수 있습니다.

이 연산자는 X의 리트윗 기능을 사용하는 실제 리트윗만 찾습니다. 인용 트윗과 X의 리트윗 기능을 사용하지 않은 수정 게시물은 이 연산자에 매칭되지 않습니다.



참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
is:reply게시물이 답글인지 여부로 필터링하는 연산자입니다. 규칙과 일치하는 명시적 답글만 전달합니다. 또한 부정을 사용하여 규칙과 일치하는 답글을 제외할 수 있습니다.

이 연산자는 유료 프리미엄 및 엔터프라이즈 검색에서만 제공되며, 샌드박스 개발 환경에서는 제공되지 않습니다.



참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
is:quote인용 트윗 또는 다른 게시물을 참조하는 게시물만 전달합니다. 이는 게시물 페이로드의 “is_quote_status”:true로 식별됩니다. 또한 부정을 사용하여 인용 트윗을 제외할 수 있습니다.

참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
is:verified작성자가 X에 의해 “인증됨”인 게시물만 전달합니다. 또한 부정을 사용하여 작성자가 인증된 게시물을 제외할 수 있습니다.


참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
has:mentions다른 X 사용자를 언급한 게시물을 매칭합니다.


참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
has:hashtags해시태그를 포함한 게시물을 매칭합니다.


참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
has:media사용 가능한 별칭: has:media_link

X에서 분류한 미디어 URL을 포함하는 게시물을 매칭합니다. 예: pic.x.com.


참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
has:imagesX에서 분류한 미디어 URL을 포함하는 게시물을 매칭합니다. 예: pic.x.com.


참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
has:videos사용 가능한 별칭: has:video_link

X에 직접 업로드된 네이티브 X 동영상을 포함하는 게시물을 매칭합니다. Vine, Periscope에서 만든 동영상이나 다른 동영상 호스팅 사이트로의 링크가 있는 게시물은 매칭되지 않습니다.


참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.
has:symbols캐시태그 기호(앞에 ‘’문자가붙은)를포함하는게시물을매칭합니다.예:’ 문자가 붙은)를 포함하는 게시물을 매칭합니다. 예: tag. 이 연산자는 enterprise 검색 API에서만 사용할 수 있습니다.


참고: Search API를 사용할 때 이 연산자는 is: 또는 has:를 포함하지 않는 다른 연산자와 함께 사용해야 합니다.

​
제품 개요

엔터프라이즈 티어의 Full-archive Search는 2015년 8월에 출시되었고, 프리미엄 티어 버전은 2018년 2월에 출시되었습니다. 이 검색 제품을 통해 고객은 공개된 모든 게시물에 즉시 접근할 수 있습니다. Full-archive Search에서는 단일 쿼리를 제출하고 전통적인 RESTful 방식으로 응답을 받습니다. Full-archive Search는 응답당 최대 500개 게시물의 페이지네이션을 구현하며, 프리미엄은 분당 최대 60회(rpm), 엔터프라이즈는 분당 120회까지의 속도 제한을 지원합니다. 이러한 사항을 고려하면 Full-archive Search는 동시 요청을 활용해 게시물을 빠르고 대규모로 검색할 수 있습니다. 디스크에 저장된 게시물 플랫 파일 집합을 기반으로 하는 Historical PowerTrack과 달리, Full-archive Search의 게시물 아카이브는 온라인 데이터베이스와 유사합니다. 모든 데이터베이스와 마찬가지로 콘텐츠를 대상으로 쿼리를 수행할 수 있습니다. 또한 고성능 데이터 검색을 위해 인덱스(index)를 사용합니다. Full-archive Search 엔드포인트에서 쿼리 언어는 PowerTrack 연산자로 구성되며, 각 연산자는 인덱싱된 게시물 JSON 속성에 대응합니다. 또한 Historical PowerTrack과 마찬가지로, 쿼리 시점의 현재 상태를 반영하는 게시물 속성이 있습니다. 예를 들어 오늘 Search API를 사용해 2010년에 게시된 게시물에 접근하는 경우, 사용자의 프로필 설명, 계정 ‘home’ 위치, 표시 이름, 그리고 즐겨찾기 및 리포스트 수에 대한 게시물 지표는 2010년 당시가 아니라 오늘 기준 값으로 업데이트됩니다. 

​
메타데이터 타임라인

아래는 전체 보관소 검색 엔드포인트 연산자가 매칭을 시작한 시점의 타임라인입니다. 경우에 따라 연산자 매칭은 X에서 ‘커뮤니케이션 관례’가 널리 자리 잡은 훨씬 이후에 시작되었습니다. 예를 들어, @Replies는 2006년에 사용자 관례로 등장했지만, ‘지원’ JSON과 함께하는 일급 객체 또는 이벤트가 된 것은 2007년 초였습니다. 따라서 2006년의 @Replies를 매칭하려면 to: 및 in_reply_to_status_id: PowerTrack 연산자에 의존하기보다 게시물 본문을 살펴봐야 합니다. 여기에 제공된 세부 정보는 전체 보관소 검색(수백 건의 검색을 기반)으로 생성되었습니다. 이 타임라인은 100% 완전하거나 정확하지 않을 수 있습니다. 사용 사례에 필수적인 다른 필터링/메타데이터의 ‘생성 시점’을 확인하신 경우 알려주시기 바랍니다. 기본이 되는 검색 인덱스는 재구성될 수 있습니다. 따라서 이 타임라인의 세부 정보는 변경될 수 있습니다.

​
2006

  • 3월 26일 - lang:. 검색 인덱스를 생성하는 과정에서 게시물 메타데이터가 소급 반영된 사례.
  • 7월 13일 - has:mentions 매칭 시작.
  • 10월 6일 - has:symbols. 주식 종목을 논의할 때 쓰는 cashtags(또는심볼)은2009년초가되어서야일반화되었습니다.그전까지의대부분사용은속어에가까웠습니다(예:cashtags(또는 심볼)은 2009년 초가 되어서야 일반화되었습니다. 그전까지의 대부분 사용은 속어에 가까웠습니다(예: slang).
  • 10월 26일 - has:links 매칭 시작.
  • 11월 23일 - has:hashtags 매칭 시작.

​
2007

  • 1월 30일 - 최초의 일급 @reply(in_reply_to_user_id), reply_to_status_id: 매칭 시작.
  • 8월 23일 - 주제와 대화를 정리하기 위한 일반적인 관례로 해시태그 등장. 실제 첫 사용은 일주일 후.

​
2009

  • 5월 15일 - is:retweet. 이 연산자는 공식 Retweets의 ‘베타’ 출시와 “Via @” 패턴부터 매칭되기 시작한다는 점에 유의하세요. 이 베타 기간 동안 Post 동사는 ‘post’이며, 원본 Post는 페이로드에 포함되지 않습니다.
  • 8월 13일 - “RT @” 패턴, 동사 ‘share’ 설정, 원본 Post를 담는 ‘retweet_status’ 속성과 함께 공식 Retweets의 최종 버전이 출시됩니다(이에 따라 JSON 페이로드 크기가 대략 두 배가 됩니다).

​
2010

  • 3월 6일 - has:geo, bounding_box:, point_radius: 지리 연산자 매칭 시작.
  • 8월 28일 - has:videos (2015년 2월까지 이 연산자는 youtube.com, vimeo.com, vivo.com 등 일부 동영상 호스팅 사이트 링크가 포함된 게시물과 매칭됩니다).

​
2011

  • 7월 20일 - has:media 및 has:images 일치 항목 지원 시작. 네이티브 사진은 2010년 8월 9일 공식 발표됨.

​
2014

  • 12월 3일 - (대략) 일부 확장 URL 메타데이터가 HTML 제목과 설명과 함께 페이로드에 포함되기 시작했습니다. 이 확장 메타데이터는 2016년 5월에 보다 완전한 형태로 도입되었습니다.

​
2015

  • 2월 10일 - has:videos가 X의 ‘네이티브’ 동영상과 일치합니다.
  • 2월 17일 - has:profile_geo, profile_country:, profile_region:, profile_locality: 프로필 지오 연산자의 일치가 시작됩니다.
  • 2월 17일 - place_country: 및 place: 게시물 지오 연산자의 일치가 시작됩니다.

​
2016

​
2017

  • 2월 22일 - 설문조사 메타데이터가 확장된 네이티브 형식으로 제공됩니다. 이 메타데이터와 관련된 오퍼레이터는 없습니다.

​
2022

  • 9월 27일 - 이 날짜 이후에 생성된 모든 게시물 객체에는 편집된 게시물 메타데이터가 제공됩니다. 게시물 객체를 제공하는 모든 Enterprise 엔드포인트는 이 날짜부터 해당 메타데이터를 제공하도록 업데이트되었습니다. 제공되는 편집 메타데이터에는 edit_history 및 edit_controls 객체가 포함됩니다. 이러한 메타데이터는 2022년 9월 27일 이전에 생성된 게시물에는 반환되지 않습니다. 현재 이 메타데이터와 일치하는 Enterprise 오퍼레이터는 제공되지 않습니다. 편집 게시물 메타데이터에 대해 자세히 알아보려면 Edit Posts 기본 사항 페이지를 참조하세요.

​
2022

  • 9월 29일 - 이 날짜 이후에 생성된 모든 게시물 객체에는 수정된 게시물 메타데이터가 제공됩니다. 게시물 객체를 제공하는 모든 Enterprise 엔드포인트는 이 날짜부터 이 메타데이터를 제공하도록 업데이트되었습니다. 제공되는 수정 메타데이터에는 edit_history 및 edit_controls 객체가 포함됩니다. 이 메타데이터는 2022년 9월 27일 이전에 생성된 게시물에는 반환되지 않습니다. 현재 이 메타데이터에 대응하는 Enterprise 연산자는 제공되지 않습니다. 수정된 게시물 메타데이터에 대해 자세히 알아보려면 Edit Posts 기본 사항 페이지를 확인하세요.

​
필터링 팁

위의 타임라인 정보를 종합하면 Search API 필터를 작성할 때 고려해야 할 세부 사항이 매우 많다는 것을 알 수 있습니다. 핵심적으로 다음 두 가지를 유념하세요.
  • 일부 메타데이터에는 ‘born-on’ 날짜가 있어 필터가 거짓 음성을 발생시킬 수 있습니다. 이러한 검색에는 해당 기간 전체 또는 일부에 존재하지 않았던 메타데이터에 의존하는 연산자(Operator)가 포함됩니다. 예를 들어 has:images 연산자로 게시물을 검색하면 2011년 7월 이전 기간에는 일치 결과가 없습니다. 이 연산자는 X 사용자 인터페이스를 통해 게시물에 첨부된 네이티브 사진과 일치하기 때문입니다. 사진 공유 게시물의 보다 완전한 데이터 세트를 얻으려면 2011년 7월 이전에는 사진 호스팅에 널리 쓰이던 URL에 일치하는 규칙 절을 포함해야 합니다.
  • 일부 메타데이터는 게시물이 X에 게시된 이후 시점의 메타데이터로 보강(백필)되었습니다.
PowerTrack 쿼리를 작성할 때 일반적으로 중점적으로 살피는 속성 유형은 다음과 같습니다.
  • X 프로필
  • 원본 또는 공유된 게시물
  • 게시물 언어 분류
  • 지리 정보가 참조된 게시물
  • 공유 링크 미디어
이 중 일부는 제품별로 동작이 다르며, 일부는 동일한 동작을 보입니다. 아래에서 자세히 설명합니다.

​
X 프로필

Search API는 조회 시점의 상태로 설정된 사용자 프로필 데이터와 함께 과거 게시물을 제공합니다. 2014년의 게시물을 요청하면 사용자의 프로필 메타데이터는 쿼리 시점에 존재하는 상태를 반영합니다.

​
원본 게시물과 리트윗

PowerTrack _is:retweet_ 연산자를 사용하면 리트윗을 포함하거나 제외할 수 있습니다. 이 연산자의 사용자는 2009년 8월 이전 데이터에 대해 리트윗 매칭(또는 비매칭)을 위한 두 가지 전략을 마련해야 합니다. 2009년 8월 이전에는 “@RT ” 패턴과의 일치를 확인하기 위해 정확한 구문 일치로 게시물 본문 자체를 검사해야 합니다(실제로 2009년 5월부터 8월 사이의 리트윗을 필터링하는 경우 “Via @” 패턴도 포함해야 합니다). 2009년 8월 이후 기간에는 is:retweet 연산자를 사용할 수 있습니다.

​
게시물 언어 분류

게시물의 언어 분류로 필터링할 때, X의 과거 제품들은 서로 꽤 다릅니다. Search 아카이브가 구축될 당시, 모든 게시물에 X 언어 분류가 소급 적용되었습니다. 따라서 lang: 연산자는 전체 게시물 아카이브에서 사용할 수 있습니다.

​
게시물의 지리적 참조

게시물을 지리적으로 참조하는 주요 방법은 세 가지입니다:
  • 게시물 본문 내 지리적 언급. 게시물 본문에 포함된 지리적 언급을 기준으로 매칭하는 방법은 현지 지식에 의존하기 때문에 가장 까다로운 편이지만, 전체 게시물 아카이브에 적용할 수 있는 옵션입니다. 여기는 ‘golden gate’ 필터를 기반으로 샌프란시스코 지역에서 2006년에 지리적으로 참조된 매칭 예시입니다.
  • 사용자가 지오태그한 게시물. 검색 API에서는 일부 Geo 연산자를 사용해 게시물을 매칭할 수 있는 기능이 2010년 3월에 도입되었고, 다른 일부는 2015년 2월에 추가되었습니다:
    • 2010년 3월 6일: has:geo, bounding_box:, point_radius:
    • 2015년 2월 17일: place_country:, place:
  • 사용자가 설정한 계정 프로필 ‘home’ 위치. 프로필 Geo 연산자는 Historical PowerTrack과 Search API 모두에서 사용할 수 있습니다. Search API에서는 이 프로필 Geo 메타데이터가 2015년 2월부터 제공됩니다. 프로필 Geo 메타데이터가 제공되기 이전에 게시된 게시물의 경우, 정규화되지 않은 사용자 입력과 매칭하는 데 사용할 수 있는 bio_location: 연산자가 제공됩니다.
2012년 3월에 확장 URL 보강(enrichment)이 도입되었습니다. 그 이전에는 게시물 페이로드에 사용자가 제공한 URL만 포함되었습니다. 따라서 사용자가 단축 URL을 포함한 경우 관심 있는 (확장된) URL과 매칭하기가 어려울 수 있습니다. 검색 API에서는 이 메타데이터가 2012년 3월부터 제공됩니다. 2016년 7월에는 향상 URL 보강(enhanced URL enrichment)이 도입되었습니다. 이 향상된 버전은 게시물 페이로드에 웹사이트의 HTML 제목과 설명을 추가로 제공하며, 이를 기준으로 매칭할 수 있는 연산자(Operator)도 제공합니다. 이러한 메타데이터는 2014년 12월부터 나타나기 시작합니다. 2016년 9월 X는 ‘네이티브 첨부’를 도입하여, 뒤에 오는 공유 링크가 게시물 140자 제한에 포함되지 않도록 했습니다. 이 두 가지 URL 보강은 이러한 공유 링크에도 계속 적용됩니다. 관련 검색 연산자가 매칭되기 시작한 시점은 다음과 같습니다:
  • 2006년 10월 26일 - has:links
  • 2011년 7월 20일 - has:images 및 has:media
  • 2011년 8월 - url: 및 Expanded URLs 보강 2006년 9월처럼 이른 시점에도 (url:"spotify.com" OR url:gnip OR url:microsoft OR url:google OR url:youtube)는 twitter_entities와 gnip 객체에 urls[] 메타데이터가 없음에도 불구하고 http://x.com/Adam/statuses/16602 와 매칭됩니다. “youtube.com”은 urls[] 메타데이터가 전혀 없어도 url:youtube와 매칭되는 메시지 콘텐츠의 예입니다.
  • 2015년 2월 10일 - 네이티브 동영상을 위한 has:videos. 2010/08/28부터 2015/02/10 사이에는 이 연산자가 youtube.com, vimeo.com, vivo.com 등의 일부 동영상 호스팅 사이트 링크가 포함된 게시물과 매칭됩니다.
  • 2016년 5월 1일 - Enhanced URLs 보강을 기반으로 하는 url_title: 및 url_description:이 일반 제공(GA)으로 전환. 최초의 Enhanced URL 메타데이터는 2014년 12월에 나타나기 시작했습니다.

​
자주 묻는 질문(FAQ)

​
일반 검색 게시물 API 관련 질문

counts 엔드포인트가 제공하는 결과와 data 엔드포인트가 제공하는 결과에는 알려진 차이가 있습니다. counts 엔드포인트는 사전 컴플라이언스 단계(삭제된 게시물, 위치 정보 스크럽 등과 같은 사항을 반영하지 않음)를 기준으로 하므로 결과에 불일치가 발생할 수 있는 반면, data 엔드포인트는 전달 시점에 컴플라이언스를 준수하며 모든 컴플라이언스 이벤트를 반영합니다.
이런 일이 발생했을 수 있는 몇 가지 이유가 있습니다. 예를 들면 다음과 같습니다.
  1. 기대한 게시물이 보호된 계정에서 작성된 경우
  2. 데이터 엔드포인트가 모든 컴플라이언스 이벤트를 반영하므로(삭제된 게시물, 정제된 지오 정보 등은 응답에 포함되지 않습니다)
이는 프리미엄 규칙과 필터링을 잘못 사용했을 가능성이 큽니다. 문서를 여기에서 검토하고, 규칙 작성과 관련된 제한 사항을 정확히 이해했는지 확인하세요.
네, 다음을 포함합니다:
  • Tweepy - 표준 검색/게시물 제품을 사용하는 데 적합함 (Python)
  • X API - 표준 Search Post API를 사용하는 데 적합함 (Python)
  • Search Posts Python 및 Search Posts Ruby - 엔터프라이즈(및 v2!) Search Post API에 활용하기 좋은 두 가지 도구
저희가 직접 지원하는 모든 라이브러리는 xdevplatform GitHub 페이지에서 확인할 수 있습니다: https://github.com/xdevplatform.또한 도움이 될 수 있는 기타 서드파티 라이브러리도 있습니다. 다만, 이들 중 일부는 프리미엄 및 엔터프라이즈 제품과 호환되지 않을 수 있으니 유의해 주세요.
예. 데이터 엔드포인트는 지정한 maxResults에 도달하거나 30일이 지나면 페이지네이션됩니다.예를 들어, 특정 30일 기간에 게시물이 800개라면 전체 결과를 가져오려면 두 번 요청해야 합니다. 요청당 반환 가능한 게시물의 최대 개수는 500개(maxResults)이기 때문입니다. 또한 첫 번째 달에 게시물이 400개, 두 번째 달에 100개인 경우에도 전체 결과를 가져오려면 두 번 요청해야 합니다. 첫 번째 요청에서 지정한 maxResults보다 적은 게시물이 반환되더라도 페이지네이션은 30일이 지나면 수행됩니다.
게시물은 최신순으로 반환됩니다. 예를 들어 첫 번째 페이지에는 쿼리와 일치하는 가장 최근 게시물이 표시되며, 페이지네이션은 결과의 게시 날짜가 처음 요청한 fromDate에 도달할 때까지 계속됩니다.
청구에는 원본 게시물만 반영됩니다. 이후의 모든 수정 사항은 무시되며 전체 활동 수에 포함되지 않습니다. Enterprise
당사의 엔터프라이즈 솔루션은 예측 가능한 가격으로 귀사의 요구에 맞춰 맞춤 제공됩니다. 자세한 내용은 여기에서 신청해 주세요.
  • 엔터프라이즈 Search Post API 문서는 여기를 참고하세요.
  • 규칙과 필터링에 대한 유용한 정보는 여기에서 확인할 수 있습니다.
  • 데이터 엔드포인트 사용 방법에 대한 유용한 정보는 여기에서 확인할 수 있습니다.
  • counts 엔드포인트 사용 방법에 대한 유용한 정보는 여기에서 확인할 수 있습니다.
  • 사용 가능한 연산자 목록은 여기에서 확인할 수 있습니다.
이와 관련해 도움을 받으시려면 X의 계정 담당 매니저에게 연락해 주세요.

​
오류 문제 해결 가이드

코드 404 - 찾을 수 없음
  1. 각 엔드포인트에 맞는 매개변수를 사용하고 있는지 확인하세요(예: buckets 필드는 데이터 엔드포인트가 아니라 counts 엔드포인트에서만 사용할 수 있습니다).
  2. :product, :account_name, :label 필드가 올바른지 다시 확인하세요. :label 필드는 GNIP Console(엔터프라이즈 고객 전용)에서 확인할 수 있습니다.

​
API 레퍼런스

​
엔터프라이즈 검색 API

엔터프라이즈 검색 API에는 두 가지가 있습니다:
  • 30일 검색 API - 지난 30일 내에 게시된 게시물을 제공합니다.
  • 전체 보관함 검색 API - 2006년 3월 첫 게시물부터 시작해 2006년까지 거슬러 올라가는 게시물을 제공합니다.
이 검색 API는 공통 설계를 따르며 아래 문서는 둘 모두에 적용됩니다. 2022년 9월 29일부터 생성된 게시물에는 편집 이력을 설명하는 게시물 편집 메타데이터가 포함됩니다. 자세한 내용은 “게시물 편집” 기본 사항 페이지를 참조하세요. 아래는 엔터프라이즈 검색 API와 통합할 때 필요한 주요 사항입니다:
  • 게시물 데이터 및 집계 수치(counts) 요청 방법
  • 인증
  • 페이지 매김
  • API 요청 매개변수 및 예시 요청
  • API 응답 JSON 페이로드 및 예시 응답
  • HTTP 응답 코드
엔터프라이즈 API는 낮은 지연 시간과 완전한 충실도의 쿼리 기반 접근 방식으로 게시물 보관함에 액세스할 수 있게 해줍니다. 두 API의 유일한 차이는 검색 가능한 기간으로, 직전 30일이거나 2006년부터입니다. 기간은 분 단위로 지정할 수 있습니다. 게시물 데이터는 쿼리와 일치하는 가장 최근 게시물부터 최신순으로 제공됩니다. 게시물은 게시 후 약 30초가 지나면 검색 API에서 사용할 수 있습니다.

​
메서드

엔터프라이즈 검색의 기본 URI는 https://gnip-api.x.com/search/입니다.
메서드설명
POST /search/:product/accounts/:account_name/:label지정된 PowerTrack 규칙과 일치하는 최근 30일간의 게시물을 조회합니다.
POST /search/:product/accounts/:account_name/:label/counts지정된 PowerTrack 규칙과 일치하는 최근 30일간의 게시물 수를 조회합니다.
각 항목의 의미는 다음과 같습니다:
  • :product는 요청을 보내는 검색 엔드포인트를 나타내며, 30day 또는 fullarchive입니다.
  • :account_name은 console.gnip.com에 표시되는 계정과 연결된 이름(대소문자 구분)입니다.
  • :label은 console.gnip.com에 표시되는 검색 엔드포인트와 연결된 레이블(대소문자 구분)입니다.
예를 들어, TwitterDev 계정에 레이블이 ‘prod’(production의 약자)인 30일 검색 제품이 있는 경우, 검색 엔드포인트는 다음과 같습니다: 전체 엔터프라이즈 검색 API 엔드포인트는 https://console.gnip.com에 표시됩니다. 아래에는 curl이라는 간단한 HTTP 유틸리티를 사용한 예시 요청이 몇 가지 있습니다. 이 예시들은 :product, :account_name, :label이 포함된 URL을 사용합니다. 예시를 사용하려면 URL을 본인의 정보로 업데이트하십시오.

​
인증

Enterprise 검색 API에 대한 모든 요청은 https://console.gnip.com 계정에 로그인할 때 사용하는 유효한 이메일 주소와 비밀번호 조합으로 구성된 HTTP 기본 인증을 사용해야 합니다. 자격 증명은 각 요청의 Authorization 헤더로 전달해야 합니다.

​
요청/응답 동작

fromDate와 toDate 매개변수를 사용하면 API가 지원하는 어떤 기간이든 요청할 수 있습니다. 30일 검색 API는 최근 31일의 트윗을 제공합니다(‘30일’ API라고 부르지만, 사용자가 한 달 전체를 요청할 수 있도록 31일을 제공합니다). 전체 아카이브 검색 API는 최초 트윗(2006년 3월 21일)까지 거슬러 올라가는 트윗을 제공합니다. 다만 단일 응답은 지정한 ‘maxResults’ 또는 31일 중 더 작은 값으로 제한됩니다. 일치하는 데이터 양이나 지정한 기간이 ‘maxResults’ 또는 31일을 초과하면, 남은 기간의 데이터를 페이지네이션하기 위해 사용해야 하는 ‘next’ 토큰을 받게 됩니다. 예를 들어 전체 아카이브 검색을 사용해 2017년 1월 1일부터 2017년 6월 30일까지 쿼리와 일치하는 모든 트윗을 받고자 한다고 가정해 봅시다. 요청에서 fromDate와 toDate 매개변수로 6개월 전체 기간을 지정합니다. 검색 API는 maxResults 매개변수(기본값 100)에 해당하는 수의 트윗이 담긴 첫 번째 ‘페이지’로 응답합니다. 더 많은 트윗이 있을 경우(대개 그렇습니다), API는 다음 ‘페이지’ 데이터를 요청할 수 있도록 하는 ‘next’ 토큰도 제공합니다. 이 과정은 API가 더 이상 ‘next’ 토큰을 반환하지 않을 때까지 반복됩니다. 자세한 내용은 다음 섹션을 참조하세요. 데이터 요청과 count 요청을 모두 수행할 때는 단일 응답으로 반환할 수 있는 것보다 더 많은 데이터가 있을 가능성이 큽니다. 이 경우 응답에 ‘next’ 토큰이 포함됩니다. ‘next’ 토큰은 루트 수준 JSON 속성으로 제공됩니다. ‘next’ 토큰이 제공되면 추가로 가져올 데이터가 있는 것이므로 API 요청을 계속 보내야 합니다. 참고: ‘next’ 토큰의 동작은 데이터 요청과 counts 요청에서 약간 다르며, 두 경우 모두 아래에서 예시 응답과 함께 API Reference 섹션에 설명되어 있습니다.
데이터 페이지네이션
데이터 요청은 단일 응답으로 반환할 수 있는 양을 초과하는 데이터를 생성하는 경우가 많습니다. 각 데이터 요청에는 요청당 반환할 게시물(Posts)의 최대 개수를 설정하는 파라미터가 포함됩니다. 이 maxResults 파라미터의 기본값은 100이며 10~500 범위로 설정할 수 있습니다. 쿼리가 요청에 사용한 ‘maxResults’ 값보다 더 많은 게시물과 일치하면, 응답에는 ‘next’ 토큰(루트 수준 JSON 속성)이 포함됩니다. 이 ‘next’ 토큰은 후속 요청에서 해당 쿼리에 일치하는 다음 분량의 게시물(즉, 다음 ‘page’)을 가져오는 데 사용됩니다. ‘next’ 토큰은 해당 쿼리의 마지막 ‘page’ 결과에 도달해 더 이상 ‘next’ 토큰이 제공되지 않을 때까지 계속 제공됩니다. 다음 ‘page’의 데이터를 요청하려면, 사용했다면 query, toDate, fromDate 파라미터를 포함하여 원본과 완전히 동일한 쿼리를 보내고, 이전 응답에서 받은 값을 설정한 ‘next’ 요청 파라미터도 함께 포함해야 합니다. 이는 GET 또는 POST 요청 모두에서 사용할 수 있습니다. 단, GET 요청의 경우 ‘next’ 파라미터는 URL 인코딩해야 합니다. 이전 쿼리에서 받은 ‘next’ 요소를 계속 전달하여, 해당 쿼리가 포함하는 기간의 모든 게시물을 받을 때까지 진행할 수 있습니다. ‘next’ 요소가 포함되지 않은 응답을 받으면 마지막 페이지에 도달했음을 의미하며, 지정된 쿼리와 기간에 대해 추가 데이터는 더 이상 제공되지 않습니다.
counts 페이지네이션
‘counts’ 엔드포인트는 쿼리와 관련된 트윗량을 일별, 시간별, 또는 분 단위로 제공합니다. ‘counts’ API 엔드포인트는 최대 31일치 counts 페이로드에 대해 타임스탬프가 포함된 counts 배열을 반환합니다. 31일을 초과하는 기간의 counts를 요청하면 ‘next’ 토큰이 제공됩니다. 데이터 ‘next’ 토큰과 마찬가지로, 원래와 정확히 동일한 쿼리를 다시 수행해야 하며, 이전 응답에서 받은 값을 설정한 ‘next’ 요청 파라미터도 포함해야 합니다. 31일을 초과하는 counts를 요청하는 경우 외에도 ‘next’ 토큰이 제공되는 시나리오가 또 있습니다. 쿼리량이 많은 경우 counts 생성에 시간이 오래 걸려 응답 타임아웃이 발생할 수 있습니다. 이때는 31일 미만의 counts만 받게 되지만, 전체 counts 페이로드를 계속 요청할 수 있도록 ‘next’ 토큰이 제공됩니다. 중요한 내용: 타임아웃이 발생하면 항상 완전한 “버킷”만 반환됩니다. 따라서 2.5일의 데이터는 일 단위로 계산된 2개의 완전한 “버킷”으로 제공됩니다.
추가 참고 사항
  • 검색 요청에서 fromDate 또는 toDate를 사용하면 지정한 시간 범위 내의 결과만 받습니다. 시간 범위 내의 마지막 결과 묶음에 도달하면 ‘next’ 토큰이 제공되지 않습니다.
  • ‘next’ 요소는 10~500 사이의 어떤 maxResults 값과도 함께 사용할 수 있습니다(기본값 100). maxResults는 각 응답에서 반환되는 트윗 수를 결정하지만, 최종적으로 모든 결과를 받는 것을 막지는 않습니다.
  • ‘next’ 요소는 만료되지 않습니다. 동일한 ‘next’ 쿼리를 사용하는 여러 요청은 요청 시점과 관계없이 동일한 결과를 받습니다.
  • ‘next’ 매개변수로 페이지를 이동할 때 쿼리 경계에서 중복이 발생할 수 있습니다. 애플리케이션은 이를 허용하도록 설계되어야 합니다.

​
데이터 엔드포인트

POST /search/:product/:label
엔드포인트 패턴:
이 엔드포인트는 지정된 쿼리와 기간에 대한 데이터를 반환합니다. 기간을 지정하지 않으면 시간 매개변수는 기본적으로 최근 30일로 설정됩니다. 참고: 아래 설명된 매개변수를 URL에 인코딩하면 POST 대신 GET 요청으로도 동일한 기능을 수행할 수 있습니다.
데이터 요청 매개변수
ParametersDescriptionRequiredSample Value
query최대 2,048자까지의 하나의 PowerTrack 규칙과 동일합니다(긍정 및 부정 절의 수에는 제한 없음).

이 매개변수에는 모든 연산자를 포함한 PowerTrack 규칙의 모든 부분이 포함되어야 하며, 규칙의 일부를 쿼리의 다른 매개변수로 분리하면 안 됩니다.

참고: 모든 PowerTrack 연산자가 지원되는 것은 아닙니다. 지원되는 연산자는 여기에 나열되어 있습니다.		Yes(snow OR cold OR blizzard) weather
tag태그를 사용해 규칙과 그 일치 데이터를 서로 다른 논리적 그룹으로 분리할 수 있습니다. 규칙 태그가 제공되면 해당 태그가 ‘matching_rules’ 속성에 포함됩니다.

클라이언트 측에서 원하는 매핑을 유지하기 위해 규칙별 UUID를 규칙 태그에 할당하는 것을 권장합니다.		No8HYG54ZGTU
fromDate트윗이 제공될 가장 오래된 UTC 타임스탬프(전체 아카이브 검색의 경우 2006년 3월 21일까지). 타임스탬프는 분 단위 정밀도를 가지며 포함적입니다(예: 12:00은 00분을 포함).

지정됨: toDate 매개변수 없이 fromDate만 사용하면, 지금(now())부터 fromDate까지 거슬러 올라가며 쿼리 결과를 제공합니다.

미지정: fromDate가 지정되지 않으면, API는 지금(now()) 또는 toDate(지정된 경우) 기준으로 과거 30일의 모든 결과를 제공합니다.

fromDate와 toDate 매개변수 모두 사용하지 않으면, API는 요청 시점을 기준으로 과거로 거슬러 올라가며 가장 최근 30일의 모든 결과를 제공합니다.		No201207220000
toDate트윗이 제공될 가장 최신 UTC 타임스탬프입니다. 타임스탬프는 분 단위 정밀도를 가지며 비포함적입니다(예: 11:59는 해당 시각의 59분을 포함하지 않음).

지정됨: fromDate 매개변수 없이 toDate만 사용하면, toDate 이전의 가장 최근 30일치 데이터를 제공합니다.

미지정: toDate가 지정되지 않으면, API는 지금(now())부터 fromDate까지 거슬러 올라가며 쿼리의 모든 결과를 제공합니다.

fromDate와 toDate 매개변수 모두 사용하지 않으면, API는 요청 시점을 기준으로 과거로 거슬러 올라가며 전체 30일 인덱스의 모든 결과를 제공합니다.		No201208220000
maxResults요청이 반환할 검색 결과의 최대 개수입니다. 10부터 시스템 한도(현재 500) 사이의 숫자여야 합니다. 기본적으로 요청 응답은 100개의 결과를 반환합니다.No500
next여기에 설명된 대로 다음 ‘페이지’의 결과를 가져오는 데 사용됩니다. 이 매개변수에 사용하는 값은 API 응답에서 직접 가져온 것이며 수정해서는 안 됩니다.NoNTcxODIyMDMyODMwMjU1MTA0
추가 세부 정보
사용 가능 기간30일: 최근 31일
전체 아카이브: 2006년 3월 21일 - 현재
쿼리 형식최대 2,048자(긍정/부정 절의 개수에는 제한 없음)로 구성된 단일 PowerTrack 규칙과 동일합니다.

참고: 모든 PowerTrack 연산자가 지원되는 것은 아닙니다. 지원되는 연산자 목록은 Available operators를 참조하세요.
요청 한도파트너에게는 분 및 초 단위로 요청 한도가 적용됩니다. 분당 요청 한도는 계약에 명시된 대로 파트너별로 달라집니다. 다만, 이 분당 한도를 단일 버스트로 사용하는 것은 의도된 바가 아닙니다. 분당 요청 한도와 무관하게, 모든 파트너는 데이터 및/또는 counts에 대한 모든 요청을 합산하여 초당 최대 20건의 요청으로 제한됩니다.
컴플라이언스Full-Archive Search API를 통해 전달되는 모든 데이터는 전달 시점에 준수 상태입니다.
실시간 가용성데이터는 X 플랫폼에서 생성된 후 30초 이내에 인덱스에 반영됩니다
예시 데이터 요청 및 응답
예시 POST 요청
  • POST 요청의 매개변수는 아래와 같이 JSON 형식의 본문으로 전송됩니다.
  • 조회하려는 PowerTrack 규칙의 모든 요소(예: 키워드, bounding_box: 같은 기타 연산자)는 ‘query’ 매개변수에 포함해야 합니다.
  • 규칙의 일부를 쿼리 URL에서 별도의 매개변수로 분리하지 마세요.
다음은 초기 데이터 요청을 위한 POST(cURL 사용) 명령 예시입니다: 
    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label.json" -d '{"query":"from:twitterDev","maxResults":500,"fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm"}'
API 데이터 응답에 ‘next’ 토큰이 포함되어 있다면, 아래는 제공된 토큰을 ‘next’ 매개변수로 설정해 원래 요청에 이어 보내는 후속 요청의 예입니다: 
    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label.json" -d '{"query":"from:twitterDev","maxResults":500,"fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm",
    "next":"NTcxODIyMDMyODMwMjU1MTA0"}'
GET 요청 예시
  • GET 요청의 매개변수는 표준 URL 인코딩을 사용해 URL에 인코딩됩니다.
  • 조회할 PowerTrack 규칙의 모든 구성 요소(예: 키워드, bounding_box: 같은 기타 연산자)는 ‘query’ 매개변수에 포함해야 합니다.
  • 규칙의 일부를 쿼리 URL에서 별도의 매개변수로 분리하지 마세요.
다음은 초기 데이터 요청을 위한 GET(cURL 사용) 명령 예시입니다: 
    curl -u<username> "http://gnip-api.x.com/search/:product/accounts/:account_name/:label.json?query=from%3Atwitterdev&maxResults=500&fromDate=yyyymmddhhmm&toDate=yyyymmddhhmm"
예시 데이터 응답
2022년 9월 29일 이후에 생성된 Tweet에는 편집 이력을 설명하는 Tweet 편집 메타데이터가 Tweet 객체에 포함됩니다. 자세한 내용은 “Edit Tweets” 기본 사항 페이지를 참조하세요. 아래는 데이터 쿼리에 대한 예시 응답입니다. 이 예시는 사용 가능한 Tweet이 ‘maxResults’를 초과하여 이후 요청을 위한 ‘next’ 토큰이 제공되는 경우를 가정합니다. 쿼리와 연관된 Tweet이 ‘maxResults’ 이하인 경우 응답에 ‘next’ 토큰이 포함되지 않습니다. ‘next’ 요소의 값은 쿼리마다 달라지며 불투명한 문자열로 취급해야 합니다. 응답 본문에서 ‘next’ 요소는 다음과 같은 형태로 표시됩니다: 
{
    "results":
      [
            {--트윗 1--},
            {--트윗 2--},
            ...
            {--트윗 500--}
      ],
    "next":"NTcxODIyMDMyODMwMjU1MTA0",
    "requestParameters":
      {
        "maxResults":500,
        "fromDate":"201101010000",
        "toDate":"201201010000"
      }
  }
후속 요청에 대한 응답은 다음과 비슷할 수 있습니다(새로운 트윗과 달라진 ‘next’ 값에 유의하세요): 
{
      "results":
      [
            {--트윗 501--},
            {--트윗 502--},
            ...
            {--트윗 1000--}
      ],
      "next":"R2hCDbpBFR6eLXGwiRF1cQ",
      "requestParameters":
      {
        "maxResults":500,
        "fromDate":"201101010000",
        "toDate":"201201010000"
      }
  }
이전 쿼리에서 받은 ‘next’ 요소를 계속 전달해 쿼리에서 지정한 기간의 모든 트윗을 받을 때까지 이어서 요청할 수 있습니다. ‘next’ 요소가 포함되지 않은 응답을 받으면 마지막 페이지에 도달했으며 해당 기간 내에 추가로 제공할 데이터가 없음을 의미합니다.

​
Counts 엔드포인트

/search/:stream/counts
엔드포인트 패턴:
/search/fullarchive/accounts/:account_name/:label/counts.json 이 엔드포인트는 지정된 쿼리에 대한 counts(데이터 볼륨) 데이터를 반환합니다. 기간을 지정하지 않으면 시간 매개변수의 기본값은 최근 30일입니다. 데이터 볼륨은 일별, 시간별(기본), 또는 분 단위 중 하나로 타임스탬프가 있는 배열로 반환됩니다. 참고: 아래 설명된 매개변수를 URL에 인코딩하면, POST 대신 GET 요청으로도 동일한 기능을 수행할 수 있습니다.
Counts 요청 매개변수
ParametersDescriptionRequiredSample Value
query최대 2,048자의 하나의 PowerTrack 규칙과 동일합니다(긍정 및 부정 절의 개수에는 제한 없음).

이 매개변수에는 모든 연산자를 포함해 PowerTrack 규칙의 모든 부분이 포함되어야 하며, 규칙의 일부를 쿼리의 다른 매개변수로 분리해서는 안 됩니다.

참고: 모든 PowerTrack 연산자가 지원되는 것은 아닙니다. 지원되는 연산자 목록은 Available operators를 참조하세요.		Yes(snow OR cold OR blizzard) weather
fromDate제공될 Tweet의 가장 오래된 UTC 타임스탬프(2006/03/21까지). 타임스탬프는 분 단위 정밀도이며 포함 범위입니다(예: 12:00은 00분을 포함).

지정됨: toDate 매개변수 없이 fromDate만 사용하는 경우, API는 지금부터 fromDate까지 거슬러 올라가며 쿼리에 대한 counts(데이터 볼륨) 데이터를 제공합니다. fromDate가 현재로부터 31일을 초과해 과거인 경우, 요청을 페이지네이션하기 위한 next 토큰을 받게 됩니다.

미지정: fromDate가 지정되지 않은 경우, API는 지금 또는 toDate(지정된 경우) 기준 이전 30일 동안의 counts(데이터 볼륨)를 제공합니다.

fromDate와 toDate 매개변수를 모두 사용하지 않으면, API는 요청 시점부터 과거로 가장 최근 30일의 counts(데이터 볼륨)를 제공합니다.		No201207220000
toDate제공될 Tweet의 최신 UTC 타임스탬프. 타임스탬프는 분 단위 정밀도이며 비포함 범위입니다(예: 11:59는 해당 시간의 59분을 포함하지 않음).

지정됨: fromDate 매개변수 없이 toDate만 사용하는 경우, toDate 기준 직전 30일 동안의 가장 최근 counts(데이터 볼륨)를 제공합니다.

미지정: toDate가 지정되지 않은 경우, API는 fromDate까지 거슬러 올라가며 쿼리에 대한 counts(데이터 볼륨)를 제공합니다. fromDate가 현재로부터 31일을 초과해 과거인 경우, 요청을 페이지네이션하기 위한 next 토큰을 받게 됩니다.

fromDate와 toDate 매개변수를 모두 사용하지 않으면, API는 요청 시점부터 과거로 가장 최근 30일의 counts(데이터 볼륨)를 제공합니다.		No201208220000
bucketcount 데이터가 제공될 시간 단위입니다. 요청한 기간 내에서 매일, 매시간 또는 매분 단위의 count 데이터를 반환할 수 있습니다. 기본적으로 시간별 counts가 제공됩니다. 옵션: ‘day’, ‘hour’, ‘minute’Nominute
nextHERE에 설명된 대로 결과의 다음 ‘페이지’를 가져오는 데 사용됩니다. 이 매개변수의 값은 API 응답에서 그대로 가져오며 수정해서는 안 됩니다.NoNTcxODIyMDMyODMwMjU1MTA0
추가 세부정보
사용 가능 기간30일: 최근 31일
전체 보관: 2006년 3월 21일 - 현재
쿼리 형식최대 2,048자의 단일 PowerTrack 규칙과 동일합니다.

참고: 모든 PowerTrack 연산자가 지원되는 것은 아닙니다. 지원되는 연산자 목록은 사용 가능한 연산자를 참조하세요.
요청 한도파트너에게는 분 및 초 단위로 요청 한도가 적용됩니다. 분당 요청 한도는 계약에 명시된 대로 파트너별로 다릅니다. 다만 이러한 분당 한도는 단일 버스트로 사용하도록 설계되지 않았습니다. 분당 한도와 무관하게 모든 파트너는 데이터 및/또는 counts에 대한 모든 요청을 합산하여 초당 최대 20건의 요청으로 제한됩니다.
집계 정확도이 엔드포인트를 통해 제공되는 counts는 실제 발생한 Tweet 수를 반영하며, 이후의 컴플라이언스 이벤트(삭제, 위치 정보 정리)는 반영하지 않습니다. 집계에 포함된 일부 Tweet은 사용자 컴플라이언스 조치로 인해 데이터 엔드포인트에서 제공되지 않을 수 있습니다.
예제 counts 요청 및 응답
예시 POST 요청
  • 아래와 같이 POST 요청의 매개변수는 JSON 형식의 본문으로 전송됩니다.
  • 조회하려는 PowerTrack 규칙의 모든 요소(예: 키워드, bounding_box:와 같은 기타 연산자)는 ‘query’ 매개변수에 포함해야 합니다.
  • 규칙의 일부를 쿼리 URL의 별도 매개변수로 나누지 마세요.
다음은 초기 counts 요청을 수행하기 위한 예시 POST(cURL 사용) 명령입니다: 
    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label/counts.json" -d '{"query":"TwitterDev","fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm","bucket":"day"}'
API counts 응답에 ‘next’ 토큰이 포함되어 있다면, 아래는 제공된 토큰으로 ‘next’ 매개변수를 설정한 원래 요청과 동일한 형태의 후속 요청입니다: 
    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label/counts.json" -d '{"query":"TwitterDev","fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm","bucket":"day",
    "next":"YUcxO87yMDMyODMwMjU1MTA0"}'
예시 GET 요청
  • GET 요청의 요청 매개변수는 표준 URL 인코딩을 사용해 URL에 인코딩됩니다.
  • 조회 중인 PowerTrack 규칙의 모든 구성 요소(예: 키워드, bounding_box: 같은 기타 연산자)는 ‘query’ 매개변수에 포함해야 합니다.
  • 쿼리 URL에서 규칙의 일부를 별도의 매개변수로 분리하지 마세요.
다음은 초기 counts 요청을 수행하기 위한 GET(cURL 사용) 명령 예시입니다: 
    curl -u<username> "http://gnip-api.x.com/search/fullarchive/accounts/:account_name/:label/counts.json?query=TwitterDev&bucket=day&fromDate=yyyymmddhhmm&toDate=yyyymmddhhmm"

​
예시 counts 응답

아래는 counts(데이터 볼륨) 쿼리에 대한 예시 응답입니다. 이 예시 응답에는 ‘next’ 토큰이 포함되어 있으며, 이는 counts 요청 기간이 31일을 초과했거나 제출된 쿼리의 데이터량이 충분히 커서 부분 응답이 트리거되었음을 의미합니다. ‘next’ 요소의 값은 쿼리마다 달라지며 불투명한 문자열로 간주해야 합니다. 응답 본문에서 ‘next’ 요소는 다음과 같이 표시됩니다: 
    {
      "results": [
        { "timePeriod": "201101010000", "count": 32 },
        { "timePeriod": "201101020000", "count": 45 },
        { "timePeriod": "201101030000", "count": 57 },
        { "timePeriod": "201101040000", "count": 123 },
        { "timePeriod": "201101050000", "count": 134 },
        { "timePeriod": "201101060000", "count": 120 },
        { "timePeriod": "201101070000", "count": 43 },
        { "timePeriod": "201101080000", "count": 65 },
        { "timePeriod": "201101090000", "count": 85 },
        { "timePeriod": "201101100000", "count": 32 },
        { "timePeriod": "201101110000", "count": 23 },
        { "timePeriod": "201101120000", "count": 85 },
        { "timePeriod": "201101130000", "count": 32 },
        { "timePeriod": "201101140000", "count": 95 },
        { "timePeriod": "201101150000", "count": 109 },
        { "timePeriod": "201101160000", "count": 34 },
        { "timePeriod": "201101170000", "count": 74 },
        { "timePeriod": "201101180000", "count": 24 },
        { "timePeriod": "201101190000", "count": 90 },
        { "timePeriod": "201101200000", "count": 85 },
        { "timePeriod": "201101210000", "count": 93 },
        { "timePeriod": "201101220000", "count": 48 },
        { "timePeriod": "201101230000", "count": 37 },
        { "timePeriod": "201101240000", "count": 54 },
        { "timePeriod": "201101250000", "count": 52 },
        { "timePeriod": "201101260000", "count": 84 },
        { "timePeriod": "201101270000", "count": 120 },
        { "timePeriod": "201101280000", "count": 34 },
        { "timePeriod": "201101290000", "count": 83 },
        { "timePeriod": "201101300000", "count": 23 },
        { "timePeriod": "201101310000", "count": 12 },
       ],
      "totalCount": 2027,
      "next": "NTcxODIyMDMyODMwMjU1MTA0",
      "requestParameters":
        {
          "bucket": "day",
          "fromDate": "201101010000",
          "toDate": "201201010000"
        }
    }
이후 요청에 대한 응답은 다음과 같을 수 있습니다(새로운 counts 타임라인과 달라진 ‘next’ 값에 유의하세요): 
    {
      "results": [
        { "timePeriod": "201102010000", "count": 45 },
        { "timePeriod": "201102020000", "count": 76 },
         ....
        { "timePeriod": "201103030000", "count": 13 }
     ],
     "totalCount": 3288,
     "next": "WE79fnakFanyMDMyODMwMjU1MTA0",
     "requestParameters":
        {
          "bucket": "day",
          "fromDate": "201101010000",
          "toDate": "201201010000"
        }
    }
이전 쿼리에서 받은 ‘next’ 요소를 계속 전달하여 쿼리 기간의 모든 집계치를 받을 때까지 진행할 수 있습니다. ‘next’ 요소가 포함되지 않은 응답을 받으면 마지막 페이지에 도달했으며 해당 기간에 사용할 수 있는 추가 집계치가 없음을 의미합니다.

​
HTTP 응답 코드

상태텍스트설명
200OK요청이 성공했습니다. JSON 응답은 다음과 비슷합니다:
400Bad Request일반적으로 요청에 잘못된 JSON이 포함되었거나 JSON 페이로드가 전송되지 않은 경우 발생합니다.
401Unauthorized잘못된 자격 증명으로 인해 HTTP 인증에 실패했습니다. 요청에서 자격 증명을 올바르게 사용하고 있는지 확인하려면 console.gnip.com에 로그인하세요.
404Not Found요청이 전송된 URL에서 리소스를 찾을 수 없습니다. 잘못된 URL이 사용되었을 가능성이 큽니다.
422Unprocessable Entity쿼리에 유효하지 않은 매개변수가 있어 반환됩니다(예: 잘못된 PowerTrack 규칙).
429Unknown Code앱이 연결 요청 한도를 초과했습니다. 해당 JSON 메시지는 다음과 비슷합니다:
500Internal Server Error서버 측 오류가 발생했습니다. 지수 백오프 패턴으로 다시 시도하세요.
502Proxy Error서버 측 오류가 발생했습니다. 지수 백오프 패턴으로 다시 시도하세요.
503Service Unavailable서버 측 오류가 발생했습니다. 지수 백오프 패턴으로 다시 시도하세요.