ipgeolocation_io: add app file and 12 actions#20190
ipgeolocation_io: add app file and 12 actions#20190michelle0927 merged 28 commits intoPipedreamHQ:masterfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
|
Thank you so much for submitting this! We've added it to our backlog to review, and our team has been notified. |
|
Thanks for submitting this PR! When we review PRs, we follow the Pipedream component guidelines. If you're not familiar, here's a quick checklist:
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds a new ipgeolocation_io integration: app module with API key auth and HTTP helper, package.json and README, plus 14 action modules implementing geolocation, security, ASN, timezone (and conversion), astronomy (including time-series), bulk operations, and user-agent parsing against IPGeolocation.io v3. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Action as Action (Pipedream)
participant App as ipgeolocation_io.app
participant API as IPGeolocation API
participant Runner as Pipedream Runtime
Action->>App: _makeRequest(path, method, params, data, headers)
App->>API: HTTP request to https://api.ipgeolocation.io/v3/<path>?apiKey=...
API-->>App: JSON response
App-->>Action: return response
Action->>Runner: $.export("$summary", "...") and return response
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 14
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/ipgeolocation_io/actions/convert-timezone/convert-timezone.mjs`:
- Around line 108-127: The run method currently sends any mixture of _from/_to
fields to ipgeolocation_io._makeRequest which causes 400s for incomplete
conversion pairs; add input validation at the start of async run({ $ }) to
reject incomplete selectors by checking that either all coordinate fields
(lat_from, long_from, lat_to, long_to) are present or for each other mode both
peers exist (tz_from & tz_to, location_from & location_to, iata_from & iata_to,
icao_from & icao_to, locode_from & locode_to); if a required pair is missing
throw or return a clear error before calling this.ipgeolocation_io._makeRequest
so the API is only invoked with complete source/target pairs.
In `@components/ipgeolocation_io/actions/get-abuse-contact/get-abuse-contact.mjs`:
- Around line 17-21: The "ip" input is currently required but its description
says blank is allowed to use the caller's IP, so make the "ip" field optional:
in the action input schema for the symbol "ip" remove any required constraint or
explicitly mark it optional (e.g., set required: false or optional: true) so the
empty-input flow and the fallback summary branch can be reached; keep the
existing label/description unchanged.
In `@components/ipgeolocation_io/actions/get-asn/get-asn.mjs`:
- Around line 23-27: The asn input is currently defined as required; update the
asn field in the action input schema (the asn property in get-asn.mjs) to be
optional/nullable so callers can omit it and allow lookups by ip or the caller
IP fallback; specifically remove any "required" constraint or set the property
to allow undefined/null and ensure the existing summary/selection logic that
prefers asn when present still works unchanged.
In
`@components/ipgeolocation_io/actions/get-astronomy-time-series/get-astronomy-time-series.mjs`:
- Around line 71-83: In the async run method, validate this.dateStart and
this.dateEnd before calling this.ipgeolocation_io._makeRequest: ensure both are
parseable dates (e.g., new Date(...) is valid), that end >= start, and that the
span between start and end does not exceed 90 days; if any check fails, throw a
clear error message (e.g., "Invalid date format", "end date must be on or after
start date", or "date range must be <= 90 days") so the action fails fast
instead of issuing the HTTP request. Use the existing
this.dateStart/this.dateEnd identifiers and perform calculations in UTC to
compute the 90-day difference, then only proceed to the _makeRequest call when
validations pass.
In
`@components/ipgeolocation_io/actions/get-bulk-geolocation/get-bulk-geolocation.mjs`:
- Around line 51-74: In the run method, when calling
this.ipgeolocation_io._makeRequest({ ... }) you must pass the context object $
as an additional argument to ensure consistent context propagation; update the
call inside get-bulk-geolocation.mjs's run to invoke _makeRequest with $ (e.g.,
this.ipgeolocation_io._makeRequest($, { method: "POST", path: "/ipgeo-bulk", ...
})) so the request uses the action context for logging/exports and downstream
middleware.
In
`@components/ipgeolocation_io/actions/get-bulk-ip-security/get-bulk-ip-security.mjs`:
- Around line 35-51: In the run function, ensure the request context $ is
forwarded to the IPGeolocation client's internal caller by passing $ into the
call to this.ipgeolocation_io._makeRequest; update the call to include $ as an
argument so _makeRequest receives the execution context (i.e., change the
invocation inside run that currently calls
this.ipgeolocation_io._makeRequest({...}) to pass $ along with the options
object), keeping all other params (method, path, params, data) unchanged.
In `@components/ipgeolocation_io/actions/get-ip-security/get-ip-security.mjs`:
- Around line 36-47: The run method calls this.ipgeolocation_io._makeRequest
without passing the Pipedream execution context `$`; update the call in the run
function to pass `$` as an explicit argument to
this.ipgeolocation_io._makeRequest so context/exports are propagated (i.e., call
_makeRequest with $ and the existing request object), keeping the same
path/params and ensuring $.export remains correct.
In `@components/ipgeolocation_io/actions/get-timezone/get-timezone.mjs`:
- Around line 72-92: In run(), pass the execution context $ into the API call
(this.ipgeolocation_io._makeRequest) to ensure consistent context propagation,
and add a validation that latitude and longitude are provided together (e.g., if
one of this.lat or this.long is set and the other is null/undefined, throw or
return a clear error) before calling _makeRequest; also keep the existing
identifier construction (this.tz, `${this.lat},${this.long}`, this.location,
this.ip, this.iata, this.icao, this.locode) but ensure validation prevents lone
lat or long from producing an invalid identifier or API call.
In
`@components/ipgeolocation_io/actions/parse-bulk-user-agents/parse-bulk-user-agents.mjs`:
- Around line 23-30: In the run method, validate this.uaStrings before calling
this.ipgeolocation_io._makeRequest: ensure it's an array and its length is <=
50000, and if not reject/throw a clear validation error (e.g., "uaStrings must
be an array with at most 50000 entries") so oversized inputs are rejected
locally before POSTing to the /user-agent-bulk endpoint; update any callers or
tests expecting an error to handle the new validation behavior.
In `@components/ipgeolocation_io/actions/parse-user-agent/parse-user-agent.mjs`:
- Around line 23-33: The run function should pass the automation context `$`
into the API call and truncate long user-agent strings in the summary: update
the call to this.ipgeolocation_io._makeRequest to include `$` as the first
argument, and change the $.export("$summary", ...) to include a shortened
version of this.uaString (e.g., limit to ~120 chars and append "…" when
truncated) so summaries remain readable while still showing caller context.
In `@components/ipgeolocation_io/ipgeolocation_io.app.mjs`:
- Line 1: Remove the redundant top-of-file comment that repeats the filename
(the line "// ipgeolocation_io.app.mjs") from
components/ipgeolocation_io/ipgeolocation_io.app.mjs; simply delete that comment
so the file starts with the actual module code (ensure you do not remove any
other surrounding code or alter exports/functions in the module).
In `@components/ipgeolocation_io/package.json`:
- Around line 4-11: Update the package.json "main" entry so it points to the
built entry inside the dist folder (currently "ipgeolocation_io.app.mjs" at
project root) to match the "files": ["dist"] setting; locate the package.json's
"main" field and change it to the corresponding path under dist (e.g., prefix
with "dist/") so the published package includes the referenced entry point.
In `@components/ipgeolocation_io/README.md`:
- Line 71: Change the sentence fragment "Moreover, If you're having trouble
connecting to IPGeolocation.io, please [contact
support](mailto:support@ipgeolocation.io)." so that "If" is lowercase ("if")
after the comma; update the text in the README entry containing that exact
sentence to read "Moreover, if you're having trouble connecting to
IPGeolocation.io, please [contact support](mailto:support@ipgeolocation.io)."
- Line 17: Remove the trailing whitespace at the end of the README sentence "The
free plan provides generous 1,000 lookups per day" so the line no longer
contains any trailing spaces; edit the line in components/ipgeolocation_io
README (the sentence itself) and save the file without extra whitespace.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: c6d89964-6590-4833-8588-5fc0d9c7bbba
📒 Files selected for processing (15)
components/ipgeolocation_io/README.mdcomponents/ipgeolocation_io/actions/convert-timezone/convert-timezone.mjscomponents/ipgeolocation_io/actions/get-abuse-contact/get-abuse-contact.mjscomponents/ipgeolocation_io/actions/get-asn/get-asn.mjscomponents/ipgeolocation_io/actions/get-astronomy-time-series/get-astronomy-time-series.mjscomponents/ipgeolocation_io/actions/get-astronomy/get-astronomy.mjscomponents/ipgeolocation_io/actions/get-bulk-geolocation/get-bulk-geolocation.mjscomponents/ipgeolocation_io/actions/get-bulk-ip-security/get-bulk-ip-security.mjscomponents/ipgeolocation_io/actions/get-geolocation/get-geolocation.mjscomponents/ipgeolocation_io/actions/get-ip-security/get-ip-security.mjscomponents/ipgeolocation_io/actions/get-timezone/get-timezone.mjscomponents/ipgeolocation_io/actions/parse-bulk-user-agents/parse-bulk-user-agents.mjscomponents/ipgeolocation_io/actions/parse-user-agent/parse-user-agent.mjscomponents/ipgeolocation_io/ipgeolocation_io.app.mjscomponents/ipgeolocation_io/package.json
components/ipgeolocation/actions/get-abuse-contact/get-abuse-contact.mjs
Show resolved
Hide resolved
components/ipgeolocation/actions/get-astronomy-time-series/get-astronomy-time-series.mjs
Show resolved
Hide resolved
components/ipgeolocation/actions/get-bulk-geolocation/get-bulk-geolocation.mjs
Show resolved
Hide resolved
…e-contact.mjs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…ulk-geolocation.mjs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…urity.mjs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…se-bulk-user-agents.mjs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…r-agent.mjs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
components/ipgeolocation_io/actions/get-bulk-geolocation/get-bulk-geolocation.mjs (1)
17-22:⚠️ Potential issue | 🟡 MinorEnforce the 50,000-entry batch limit locally.
Line 21 documents a maximum of 50,000 inputs, but
runstill sends oversized batches to/ipgeo-bulkand only fails after the POST. Add the same upfront guard used in the bulk user-agent action so this step fails fast with a clear validation error.🛠️ Proposed fix
async run({ $ }) { + if (this.ips.length > 50000) { + throw new Error("`IP Addresses or Domains` supports a maximum of 50,000 entries per request."); + } + const response = await this.ipgeolocation_io._makeRequest({ $, method: "POST",Also applies to: 51-65
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/ipgeolocation_io/actions/get-bulk-geolocation/get-bulk-geolocation.mjs` around lines 17 - 22, The action currently documents a 50,000-item limit for the ips input but does not enforce it in the run function; add an upfront validation in the run handler to check the ips array length and throw a clear validation error (e.g., "Maximum 50,000 IPs allowed") before sending the POST to /ipgeo-bulk. Locate the run function and the ips parameter definition and replicate the same guard logic used in the bulk user-agent action so oversized batches are rejected client-side rather than after the request.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/ipgeolocation_io/ipgeolocation_io.app.mjs`:
- Around line 4-7: The app export is missing a root auth/props declaration so
this.$auth.apiKey is never collected; add an auth config to the default export
by adding a props (or auth) entry that defines the API key credential (e.g., add
props: { apiKey: { type: "string", secret: true, label: "API Key" } } or use
authProvisionId/connection config depending on framework) and
include/authProvisionId if required by the platform; ensure propDefinitions
remains only for action params and do not remove references to this.$auth.apiKey
elsewhere (verify code that reads this.$auth.apiKey still works after adding the
new props/auth entry).
---
Duplicate comments:
In
`@components/ipgeolocation_io/actions/get-bulk-geolocation/get-bulk-geolocation.mjs`:
- Around line 17-22: The action currently documents a 50,000-item limit for the
ips input but does not enforce it in the run function; add an upfront validation
in the run handler to check the ips array length and throw a clear validation
error (e.g., "Maximum 50,000 IPs allowed") before sending the POST to
/ipgeo-bulk. Locate the run function and the ips parameter definition and
replicate the same guard logic used in the bulk user-agent action so oversized
batches are rejected client-side rather than after the request.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: edd1d602-c259-4c8f-87e1-47cdda9d094b
📒 Files selected for processing (8)
components/ipgeolocation_io/README.mdcomponents/ipgeolocation_io/actions/get-abuse-contact/get-abuse-contact.mjscomponents/ipgeolocation_io/actions/get-asn/get-asn.mjscomponents/ipgeolocation_io/actions/get-bulk-geolocation/get-bulk-geolocation.mjscomponents/ipgeolocation_io/actions/get-ip-security/get-ip-security.mjscomponents/ipgeolocation_io/actions/parse-bulk-user-agents/parse-bulk-user-agents.mjscomponents/ipgeolocation_io/actions/parse-user-agent/parse-user-agent.mjscomponents/ipgeolocation_io/ipgeolocation_io.app.mjs
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/ipgeolocation_io/actions/convert-timezone/convert-timezone.mjs`:
- Around line 167-170: The fallback chain for computing from/to is broken
because the template `${this.lat_from},${this.long_from}` is always truthy
(e.g., "undefined,undefined"), so replace that inline literal with a conditional
that only produces a coordinate string when both lat and long are present;
specifically, change the expressions that compute from and to (currently using
tz_from/tz_to, `${this.lat_from},${this.long_from}`,
`${this.lat_to},${this.long_to}`, location_from/location_to, iata_from/iata_to,
icao_from/icao_to, locode_from/locode_to) to instead use a guard like: if both
lat and long are non-null/defined (and non-empty) then produce `${lat},${long}`,
otherwise fall back to the next option in the chain so location_from/location_to
and IATA/ICAO/LOCODE are reachable.
In `@components/ipgeolocation_io/package.json`:
- Around line 9-11: The package.json "files" array currently only lists
"dist/app/ipgeolocation_io.app.mjs", so the built actions under actions/ won't
be published; update the "files" array in
components/ipgeolocation_io/package.json to include the whole build output
(e.g., replace the single-file entry with "dist" or add "dist" alongside other
entries) so that all compiled files (including the actions directory) are
included when the package is published.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: f3dd7060-bf32-4e76-8a01-153c73671252
📒 Files selected for processing (4)
components/ipgeolocation_io/actions/convert-timezone/convert-timezone.mjscomponents/ipgeolocation_io/actions/get-astronomy-time-series/get-astronomy-time-series.mjscomponents/ipgeolocation_io/ipgeolocation_io.app.mjscomponents/ipgeolocation_io/package.json
components/ipgeolocation_io/actions/convert-timezone/convert-timezone.mjs
Outdated
Show resolved
Hide resolved
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (2)
components/ipgeolocation_io/actions/get-timezone/get-timezone.mjs (1)
72-86:⚠️ Potential issue | 🟡 MinorReject partial coordinate lookups before calling
/timezone.
latandlongare one selector, butrun()currently forwards either field independently. That turns a simple input mistake into an avoidable API error.🔧 Suggested fix
async run({ $ }) { + if ((this.lat && !this.long) || (!this.lat && this.long)) { + throw new Error("Latitude and Longitude must be provided together."); + } const response = await this.ipgeolocation_io._makeRequest({ path: "/timezone", params: {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/ipgeolocation_io/actions/get-timezone/get-timezone.mjs` around lines 72 - 86, In run(), before calling this.ipgeolocation_io._makeRequest, validate the coordinate pair: if one of this.lat or this.long is provided without the other, reject early (throw an error or return a rejected Promise) with a clear message and do not call _makeRequest; otherwise proceed and include both values in the params object. Target the run function and the params construction (this.lat, this.long, and ipgeolocation_io._makeRequest) so partial coordinate lookups are blocked and only complete lat/long pairs are forwarded to the /timezone endpoint.components/ipgeolocation_io/ipgeolocation_io.app.mjs (1)
2-5:⚠️ Potential issue | 🔴 CriticalDeclare the API key credential on the app export.
Line 68 reads
this.$auth.apiKey, but this export never defines an auth field. The connect-account flow has nothing to collect, so every action ends up sending an undefined credential.🔧 Suggested fix
export default { type: "app", app: "ipgeolocation_io", + props: { + apiKey: { + type: "string", + label: "API Key", + description: "Your IPGeolocation.io API key.", + secret: true, + }, + }, propDefinitions: {#!/bin/bash sed -n '1,120p' components/ipgeolocation_io/ipgeolocation_io.app.mjs printf '\n--- auth declarations / usages ---\n' rg -n '^\s*props\s*:|^\s*authProvisionId\s*:|\$auth\.apiKey' components/ipgeolocation_io/ipgeolocation_io.app.mjs🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/ipgeolocation_io/ipgeolocation_io.app.mjs` around lines 2 - 5, The app export is missing an auth declaration so references to this.$auth.apiKey return undefined; update the default export object to include an auth field that declares an API key credential (so this.$auth.apiKey is populated), e.g. add an auth property on the export default with type set for an API key credential and a simple test/validation entry; update the export that currently contains type, app, and propDefinitions to include this auth configuration so actions that reference this.$auth.apiKey receive the collected key.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/ipgeolocation_io/actions/convert-timezone/convert-timezone.mjs`:
- Around line 108-144: The run method currently only validates completeness but
allows multiple selector modes to be populated simultaneously; update run to
detect and reject requests that provide more than one selector mode by computing
which selector modes are present (use existing helpers:
hasPair(this.tz_from,this.tz_to), hasPair(this.location_from,this.location_to),
hasPair(this.iata_from,this.iata_to), hasPair(this.icao_from,this.icao_to),
hasPair(this.locode_from,this.locode_to), and hasFullCoordSet for coordinates)
and if the count of truthy modes is > 1 throw a clear Error (e.g., "Provide
exactly one selector mode: timezone, location, IATA, ICAO, UN/LOCODE, or
coordinates"); keep the existing completeness checks but add this exclusive-mode
validation before proceeding to choose the first match.
In
`@components/ipgeolocation_io/actions/get-astronomy-time-series/get-astronomy-time-series.mjs`:
- Around line 85-97: The get-astronomy-time-series action is sending half-filled
coordinates; add validation in the method before calling
this.ipgeolocation_io._makeRequest to reject when only one of this.lat or
this.long is provided (accept both present or both absent), throwing or
returning a clear error (e.g., "lat and long must be provided together") so the
request is not made with incomplete coordinate pairs; locate this check in the
get-astronomy-time-series action (around where this.dateStart/this.dateEnd are
used) and mirror the validation logic used for other astronomy actions to ensure
consistent behavior.
- Around line 72-84: The current creation of start/end using new
Date(`${this.dateStart}T00:00:00Z`) silently normalizes invalid calendar dates
(e.g., 2026-02-30); add strict calendar-date validation for this.dateStart and
this.dateEnd before constructing start/end: first verify the strings match
/^\d{4}-\d{2}-\d{2}$/ then parse year, month, day integers and build a UTC date
(Date.UTC) and confirm the resulting date's year/month/day equal the parsed
values; if validation fails throw the same user-facing error, and then proceed
to compute start, end, compare end < start and diffDays > 90 as before
(references: this.dateStart, this.dateEnd, start, end, diffDays).
In `@components/ipgeolocation_io/actions/get-astronomy/get-astronomy.mjs`:
- Around line 60-72: In run(), enforce the documented latitude/longitude pairing
by validating this.lat and this.long before calling
this.ipgeolocation_io._makeRequest: if one of this.lat or this.long is provided
without the other, throw a clear error (or reject) and do not call the request;
otherwise include both in the params. Update the input validation in the run()
function (where path "/astronomy" and params are assembled) to perform this
check and fail fast.
---
Duplicate comments:
In `@components/ipgeolocation_io/actions/get-timezone/get-timezone.mjs`:
- Around line 72-86: In run(), before calling
this.ipgeolocation_io._makeRequest, validate the coordinate pair: if one of
this.lat or this.long is provided without the other, reject early (throw an
error or return a rejected Promise) with a clear message and do not call
_makeRequest; otherwise proceed and include both values in the params object.
Target the run function and the params construction (this.lat, this.long, and
ipgeolocation_io._makeRequest) so partial coordinate lookups are blocked and
only complete lat/long pairs are forwarded to the /timezone endpoint.
In `@components/ipgeolocation_io/ipgeolocation_io.app.mjs`:
- Around line 2-5: The app export is missing an auth declaration so references
to this.$auth.apiKey return undefined; update the default export object to
include an auth field that declares an API key credential (so this.$auth.apiKey
is populated), e.g. add an auth property on the export default with type set for
an API key credential and a simple test/validation entry; update the export that
currently contains type, app, and propDefinitions to include this auth
configuration so actions that reference this.$auth.apiKey receive the collected
key.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: eb1bd6e9-ad4b-4f32-8d0b-942248bb0b9d
📒 Files selected for processing (5)
components/ipgeolocation_io/actions/convert-timezone/convert-timezone.mjscomponents/ipgeolocation_io/actions/get-astronomy-time-series/get-astronomy-time-series.mjscomponents/ipgeolocation_io/actions/get-astronomy/get-astronomy.mjscomponents/ipgeolocation_io/actions/get-timezone/get-timezone.mjscomponents/ipgeolocation_io/ipgeolocation_io.app.mjs
components/ipgeolocation_io/actions/get-astronomy-time-series/get-astronomy-time-series.mjs
Outdated
Show resolved
Hide resolved
components/ipgeolocation_io/actions/get-astronomy-time-series/get-astronomy-time-series.mjs
Outdated
Show resolved
Hide resolved
…y.mjs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…get-astronomy-time-series.mjs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
michelle0927
left a comment
There was a problem hiding this comment.
Approved! Ready for Release!
|
✅ All tests passed - ready for release!
|
WHY
IPGeolocation.io provides a suite of real-time IP intelligence APIs covering
geolocation, security threat detection, ASN lookup, abuse contacts, timezone
conversion, user-agent parsing, and astronomy data. This PR adds the initial
app file and 12 actions to integrate these APIs with Pipedream workflows.
WHAT
ipgeolocation_io.app.mjswithpropDefinitionsand_makeRequestmethodget-geolocation— IP/domain geolocation lookupget-bulk-geolocation— Bulk geolocation for up to 50,000 IPsget-ip-security— Threat intelligence for an IPget-bulk-ip-security— Bulk threat intelligence for up to 50,000 IPsget-asn— ASN details including peers, routes, and WHOISget-abuse-contact— Abuse contact info for an IPget-timezone— Timezone lookup by IP, coordinates, city, IATA, etc.convert-timezone— Timezone conversion between two locationsparse-user-agent— Parse a single user agent stringparse-bulk-user-agent— Parse up to 50,000 user agent stringsget-astronomy— Sunrise, sunset, moon phase for any locationget-astronomy-time-series— Astronomy data for a date range up to 90 daysREADME.mdwith overview, example use cases, getting started, and troubleshootingSummary by CodeRabbit
New Features
Documentation